Reference syntax. Like what the fuck is the difference between .. (2 dots) and ... (3 dots)? And is there .... (4 dots)?
And I can never keep apart how to compare references. If I want to compare my feature branch with master, is it git diff HEAD..master or git diff master..HEAD? It seems like in git the syntax is reversed to mine, but I’m never sure. Maybe something like git diff HEAD->master would be more intuitive?
And git rebase --onto. Fuck me did it take me a long time to understand that (if I understood it).
Honestly, that’s just git CLI interface stuff. Every time I’ve tried to read about the internal workings of git, the naming has thrown me off and stopped me from continuing. Like what the fuck is “git porcelain”? IIRC there’s also git plumbing? But that doesn’t even seem to be the internals which have another bizarre name?
git is a large series of Chesterton’s fences that should be each examined. I’m hopeful that somebody or some org will come around to design a version control system from the ground up with documented architecture from the start (and not written in gosh-darn C).
I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git’s data model. A data-first approach with blob, tree, commit, and tag can be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.
Reference syntax. Like what the fuck is the difference between
..(2 dots) and...(3 dots)? And is there....(4 dots)?And I can never keep apart how to compare references. If I want to compare my feature branch with master, is it
git diff HEAD..masterorgit diff master..HEAD? It seems like in git the syntax is reversed to mine, but I’m never sure. Maybe something likegit diff HEAD->masterwould be more intuitive?And
git rebase --onto. Fuck me did it take me a long time to understand that (if I understood it).Honestly, that’s just git CLI interface stuff. Every time I’ve tried to read about the internal workings of git, the naming has thrown me off and stopped me from continuing. Like what the fuck is “git porcelain”? IIRC there’s also
git plumbing? But that doesn’t even seem to be the internals which have another bizarre name?gitis a large series of Chesterton’s fences that should be each examined. I’m hopeful that somebody or some org will come around to design a version control system from the ground up with documented architecture from the start (and not written in gosh-darn C).Anti Commercial-AI license
I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git’s data model. A data-first approach with
blob,tree,commit, andtagcan be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.