Git Exercises

That's an interesting paper.

> More often than not, the choice of words makes sense in connection with the implementation of various git operations, but has no relation to the task you're attempting to accomplish.

This seems like an extremely common problem in computing. I support several applications and a lot of the fields and functions in those applications seem to be placed arbitrarily until you know that those fields live in the same table or those functions are a part of the same module or class. Users find the organization very confusing because the model of what they need when doesn't match how it's organized in the system. The user shouldn't need to know about those sorts of implementation details because that knowledge isn't their problem. The program interface should follow a natural workflow, not force the user's workflow to match the implementation.

> IMO, the main thing missing is a way of seeing git's core data structures updated in real-time as you perform various operations on them.

I think that would be a great help for troubleshooting those really obscure or weird situations, but I don't think that's information that your average git user should feel like they need to know to get work done.

From SVN I cut my teeth on Hg/Mercurial, which had a much simpler barrier to entry and feels more user friendly. Mercurial and git solve the same basic underlying problem, distributed repositories, but in the "next gen vcs war" (if that was even a thing), git won out by a huge landslide largely due to a little site called Github.

As I've dived into the nitty gritty of both, I find it seems you can get more out of git because it just exposes those internal structures unabashedly. I believe it's those guts that make git as powerful or as hard as it currently is on UX. To use a loose analogy, git feels like man pages: rocket science speak but incredibly dense whereas Mercurial is like a very lightweight howto site. It's easier to transition to Mercurial but once you find you need to dive deep, it's just about as complex as git. Git seems to throw you in the deep end immediately which I do think is more of a blessing than a curse but there are times when it doesn't quite feel that way.

> This seems like an extremely common problem in computing.

I agree—I see it all over the place. It's what you get for a UI by default, if you don't take any extra measures to seek an effective design: you just expose program internals.

I think the situation with git is slightly different from that all too common, naive pattern, though. The best comparison I can make is to graphics APIs like OpenGL (or even better, Vulcan), which are there in large as a means of giving access to graphics hardware, very low-level and a horrible impedance mismatch for actually describing moving images. However, they are necessary because the variety of things people might want to do with a graphics card is so vast, that 'nicer' abstractions will always also be restrictions on capabilities. So, you get OpenGL/Vulcan and rather than using it directly to build applications, it's the basis for building other graphics libraries which actually have good usability. (But also like git, there are many cases where people just need to use the low-level APIs directly, despite poor usability.)

Git seems to be addressing a similar issue in that any abstraction over the internal core data structures ends up limiting the vast spectrum of potential use cases, so it makes the compromise of providing (relatively) un-abstracted access to the program's core data structures, which maximizes use-cases covered, and sacrifices usability. But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it... I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead.

As far as visualization of its data structures goes, I see it fitting in as training wheels essentially: it would be an effective way of teaching people how the program works by allowing them to see the direct impact of particular git commands on the git data structures. Eventually you stop using it, except for troubleshooting really weird/obscure situations, as you mention. (More generally, I could see open source projects offering a flag so that their core data structures are visualized or not as a means of more effectively/enjoyably teaching new developers how data moves around in the app at a high level.)

Thanks for telling, I found the rebase extension on my own but I don't know what Mercurial users are using unless you tell me and I would not have found the evolve extension on my own :D

I will probably check it out, to be fair it seems unlikely to "unseat the incumbent" git, but I've sampled my fair share of VCS including Git, SVN, CVS, RCS, Fossil, and have never really made it around to Mercurial. None of those others that I know of recently seem to have a vocal following, other than both of Git and Mercurial now, I guess.

you clearly never had to support developers that need to work with a basic git-flow and get merge conflicts because they're unable to figure out why they shouldn't do the same change in separate branches. Or, if they do, how to resolve that conflict themselves.