Proposal: Designate commits as minor edits in Git

Git blame: A reliable rat

A great benefit of version control systems is that they make it possible to see who introduced substantive changes in the past. For example in Git, git blame <file> will reveal who last edited each line of code in <file>.

Despite the cheeky name, the greatest value of git blame isn’t so much blaming others for their mistakes, as identifying who to confer with when proposing changes. The last developer to touch a line of code may have an interest in its current state, can answer questions about it, and may have valuable perspective that will improve your proposed changes.

Slow standards adoption? Blame blame.

Unfortunately, this is an obstacle to the adoption of consistent code standards in an open source project like WordPress.

Any patches you make to legacy code whose soul purpose is applying coding standards, without introducing substantive changes, will make you appear as the last author in git blame, losing valuable information about whoever made the last substantive changes. Thus, this type of edits is discouraged.

As a result, WordPress’ adoption of its own coding standards in core code slows way down.

This is a bummer, because there would be dozens of people happy to make core contributions strictly to apply code standards. It’d be a great way for newbies to learn the ropes while making incremental improvements to code quality.

How about “minor commits” that blame is blind to?

Wouldn’t it be nice if you could indicate that a change is minor edit when you commit it? git blame would skip over these minor edits to display only substantive edits from older, non-minor commits. Obstacle to code standards adoption solved.

This could look something like $ git commit --minor <file to commit>.

Implementation considerations (wherein I wade way out past my depth)

For this to work, I’m aware of at least three things that would need to change in Git’s internals:

  1. Implement the --minor flag (or whatever) in git commit
  2. Extend data model in commit blobs (the files where Git stores its object data) to include optional metadata that means “this is a minor edit”.
  3. Make git blame aware of “this is a minor edit” metadata and crawl as far up the tree as needed to encounter an edit that is not minor.

Number 3 would add a bit of performance overhead to running git blame. I could be way off here, but I doubt that’s a deal breaker.

Number 2 might be, though. The structure of commit blobs is super lean — just a reference to a tree describing the current file structure, the commit’s author, the commit message, and a reference to parent commit object(s). Nothing more. Thus, adding metadata to support this type of feature could increase every commit’s size by a significant percentage, and that would add up when applied to an entire repository’s object graph. Would that be justified by the limited utility that a minor edit functionality would add?

Perhaps this isn’t such a big issue, as that “minor” metadata flag could either be set to true, or be nonexistent and implied to be false. This would only take up more hard disk in the cases where minor = true, instead of with 100% of commits.

Applying this to WordPress

I wrote this up with Git examples because I’m much more familiar with it, but WordPress still uses SVN for core development, and probably will for some time.

So until and unless WordPress completely migrates to Git, we’d also need an equivalent new “minor edit” feature added to SVN if we were e to benefit fully in WP developer land.

Books in demand, January 2014

I recently combined households, and schlepped several boxes of books to Powell’s to sell, which provided some interesting insights into what’s popular.

Not in demand, according to Powell’s: Lord of the Rings. Twilight. Most lit from the ’30s through the ’00s. Most four year old programming texts (covering iOS, Cocoa, Objective-C, .Net, and JavaScript).

In demand, according to Powell’s: The Silmarillion. Harry Potter. Hemingway. WordPress programming texts (even four year old ones!).

Originally published in less than 320 characters on Twitter:

Managing a business with custom WordPress

We’re building systems on top of WordPress to manage every part of our business at Rocket Lift.

The WordPress platform essentially manages content and authentication for us, gives us frameworks to build custom UI and our own functionality, and offers extra features in the form of plugins developed by a large community. It gives us everything we need to rapidly build our own custom tools that fit our own process, style, and needs.

We’re tackling the low-hanging fruit first: We’re customizing P2 to make our internal discussions less reliant on third party limitations, and we’re building a Parking Lot for action-oriented discussions we’ve identified to iterate on the way we work (We treat our Parking Lot as a sacred commitment that we need to have a conversation soon, even if we don’t have time for it right now. WordPress will help us keep these top-of-mind with simple widgets and other other UI elements to display posts of our custom post type).

We’re also dogfooding tools to tame the content management gremlins that plague our client projects. I believe I speak for all of us when I say we are so excited about these tools, and can’t wait to share then when they are ready. Soon!

And then there’s our roadmap. Which is, you know, only kind of insanely ambitious.

  • A project management calendar, building on the awesome The Events Calendar to add some features we have never seen, desperately want, and believe that you, dear reader, will find killer.
  • Internalize our task management… Basically, we want a place to store “everything I don’t need to focus on right now”, something like Asana but with a saner awareness of task relationships.
  • Dashboards to pull in data from third party services for display in custom at-a-glance views. Individuals will be empowered to build their own dashboards with custom UI building blocks we create, combined with pipes to data from awesome API-backed sources like Pipedrive, Harvest, Github, and &! plus our own WordPress-based data.
  • If Intuit continues to refuse us easy access to our data, then maybe some day in the far future we’ll ditch QuickBooks. And won’t that be satisfying.

This is a lot to tackle, even without that last whale of a wish list item. This approach violates common wisdom in lean startups that says “Don’t build what you don’t have to”. I’m the one driving this; I’m probably crazy.

Yes okay, but we’re taking this one small piece at a time. This roadmap may span years. More importantly, we do custom work with WordPress every day, and have seen its potential as an application framework grow dramatically even in the past year, thanks to the addition of fundamental tools like wp-cli and the positive trend of plugins being architected (in some cases re-architected) for extensibility and interactivity by embracing core APIs and the hooks and filters pattern. WordPress has ripened.

We’re scratching our own itch here, and we’re doing what we can with what we have, where we are. Fresh off the the high of last weekend’s WordCamp Portland, we’re emboldened to push forward with these ideas.

Right now this is just words. Stay tuned to see what we can deliver.

(Not Completely) Grokking Post Formats

Wherein I revisit a debate from a year and a half ago to stir up trouble.

WordPress 3.1 dropped in February of 2011 and introduced Post Formats, a new taxonomy indicating a post’s front-end presentation context. Formats include Aside, Status, Image, and Video among others, and the idea is for themes to vary their presentation based on what the thing is. Twitter-like post about what you’re doing right now? Give it a Status format, and smart themes will, for example, omit the title in the front-end. Short-form note? Call it an Aside, and perhaps a theme will slap an “aside” watermark in the margin and hint with typography that this is one of your less-serious works (of brilliance).

The WordPress core team decided to standardize the available formats, and not offer APIs to extend them, so that you could expect your content to port gracefully when switching to a new theme. Theme developers were evidently in an uproar about this, considering the number of articles lead developers wrote around the time of 3.1’s release to explain and clarify their rationale for rigid standardization. See Otto’s for example, and a longer list linked on the Codex page under External Resources. WordPress’ philosophy includes decisions, not options — but developers typically enjoy a back-door escape clause when the decided defaults don’t suit them, in the form of functions, filters, and hooks to add to– and override defaults. In this case, post formats fundamentally require standardization, thus extensibility would undermine the entire feature, and thus no APIs exist to add “custom post formats” (which, to be clear, do not exist — there are only the standard formats). The core team’s explanations focused on this point, and on the fact that post formats are merely a custom taxonomy, and that in fact site developers already can create their own custom alternatives if they need to, using the same APIs that core uses to implement post formats.

I get that. Standardization is important.

But, I’m also sympathetic to the themers’ desire to add to the array of standard formats without having to do any re-implementation. Re-implementation seems inelegant — I’m thinking mainly of code bloat.

I know I am extremely late to this party, but there is a compromise that seems… well, obvious to me. I can’t imagine I’m the first to consider this, and there’s probably a compelling argument against it — which I’d like to hear.

I would propose to have custom post formats that require a fallback to a standard format. In practice, when loading a post, WordPress would check to see if it’s format was supported by the theme, and if it is, it would be passed to the theme as that format, but if not, it would be passed to the theme as the standard fallback format. It would be up to the theme developer to consider graceful degradation in their design process.

I believe this would only require two API methods: (1) A function to register custom post formats, that requires you to declare a fallback to one of the standard formats. This code would be inappropriate for a theme and would belong in a plugin (because if the theme were swapped out, the database entries specifying the new custom post format would be left with garbage). (2) A function to add theme support for a specific non-standard format.

I would use a mechanism like this to, for example, register a custom format for dictionary Definitions. I’d make them fall back to the Aside format.

Can anyone explain why this isn’t a good idea?