What’s Wrong With Git? A Conceptual Design Analysis
Adrian Colyer on a paper by Santiago Perez De Rosso and Daniel Jackson (Hacker News):
The authors chose to use Git to explore the role of concepts in design – it is widely known and used, and at the same time known to be confusing and difficult to learn. Are the usability problems of git just on the surface, in the expression of the commands, or do they run deeper?
[…]
The staged and working versions of a file are coupled in complex ways, and Git commands that one might expect to affect only one often affect the other too. One way to get into trouble is to add a file, then continue working on it before committing. If you then decide to undo the commit with a reset command then depending on the arguments not just the staged version but also the working version will be replaced (wiping out subsequent work since the commit).
JC:
It’s rather weird to see the model described as such, since the underlying git model, the one that makes everything make sense it’s not even mentioned. It stays only one the surface of the command line interface, on the “porcelain” never touching the plumbing which is quite straightforward. In essence git is a layered system.
While I understand that removing the concept of staging makes things simpler to understand, I consider the staging area/index to be one of the most useful features of Git. I often make extensive changes to multiple files, which I do not want to save in a single, monolithic commit. I use the staging area to assemble fine-grained commits by carefully picking files and even individual lines. I can imagine that this could be solved without the index, but it seems a very useful concept still (like a safety net in some sense).
I like staging—don’t understand people’s issues with it. To me, Git’s model is good, but its interface could be improved.
