Thought Parsing

Most git tutorials start with teaching you a series of commands to manipulate a repository and only follow up later, if at all, with the effects those commands have on the underlying data. This is great for getting started quickly, but I think it underprepares users for more advanced usage: there's a fairly low limit to the number of opaque commands one can memorize to resolve a particular situation, and eventually every advanced user will need to learn what the underlying data model is and how git's commands manipulate it. So this tutorial is backwards: instead of starting with commands and working down to the underlying model, we'll start with the model and work up.

This tutorial was inspired by comments on this lobste.rs post.

Now that I've grabbed you with a clickbait title, let me amend: interface changes come to the table with an inherent very large negative value attached. Unless the value offered by the change is extremely high, the cost of breaking people's familiarity and use cases will vastly outweigh the benefits.

I'm specifically talking about user interfaces, here, not APIs, but I do think the same principle applies; however, APIs tend to be well-defined with simple semantics, so dealing with changes is easier and the initial cost is lower. However, with a big enough overhaul for little enough benefit or with poor enough documentation, APIs can easily fall foul of this as well. Consider Python 3, for instance, which after seven years still has remarkably poor adoption.