A PDF is available here, and analysis from Colyer 2016 is good.
This paper is fascinating in terms of ethnography. Consider: the paper mentions “branch” or “branches” dozens of times, but only says “tree” four times, and every instance is in the phrase “working tree”. The paper never mentions “blob” or “blobs”, “DAG” or “graph” or “poset”. The authors either chose to omit git’s data model, or they don’t know about it. The implication is that the UX and UI don’t reflect the data model, I suppose, but it is a very curious omission.
Now, contrast this with Git’s documentation. When sysadmins teach git, we focus on the data first. git is a kind of database which stores four different flavors of object, and the git UI is merely a collection of commands for programmatically manipulating the database. All of the various UX is purpose-built, on a per-command basis, for development workflows. New commands can be implemented as plain UINX-style executable scripts in any language.
In summary, this paper looks at git as a version-control product, while its developers and users look at git as a version-control framework.
There was a followup paper from a few years later, also with Colyer 2016 analysis; this paper has too many glaring defects to discuss here.
On a personal note, I saw this and am happy to note that science has marched along:
We plan to extend our notation to make it more expressive in the future, but are cognizant of the fact that diagrammatic syntaxes for first order logic have a long and troubled history.
Not long after this paper, ontology logs were figured out, which can be made as expressive as needed for the case of relations; see Patterson 2017.
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.
Well, I can’t read it… But I would say it’s nonsense that Git is intrinsically confusing. The core data model is extremely simple and intuitive. The problems are:
Terrible CLI.
Terrible terminology (index is probably the worse; why not draft commit?)
Bad tutorials. Lots of them explain things wrong or just confusingly
It’s a fundamentally visual problem yet so many people advise against using a GUI.
It’s like trying to explain CAD using OpenSCAD instead of SOLIDWORKS. Of course it’s going to seem like CAD is confusing.
That’s not to say Git’s data model is perfect. What’s there is decent but there are big gaps. Support for large files is bad (LFS is a hack). Support for very large projects is bad (monorepos tend to get slow and sparse checkouts are difficult; submodules have lots of issues). Conflict resolution tends to be very dumb, though I think there are some projects to improve that.
Git is a graph of commits and you can’t really display a graph in any way except visually. Even the CLI has a way of showing it visually (git log --graph).
Think about other graphs you might interact with, e.g. node graphs in 3D graphics of music production. How many of them do you manipulate with a CLI?
There should be a download link for the latest release on a project’s main page, so I don’t have to click on the releases page if I just want the current version.
I just need a GUI or some sort of visual reference. I have trouble picturing what exactly is going on with each variant of the command. I’ve been able to fuddle through it every time I do some programming, and when I used Android Studio there were some GUI tools to use but otherwise I always get so confused. I think using IDEs would help in other projects but that’s a thing that keeps me from doing programming projects on the regular.
It’s free the same way that Sublime Text is: They’ll ask for a payment once a month, but you can say you’re “evaluating it” and use it for free. If you like it enough, you can pay for it. I have.
Yea my take with git for a while is that it is a naturally GUI oriented app/program much like text editors (who uses ed any more?), however much you’re a CLI only person.
Because it’s for managing code, and the moment you get used to or want syntax highlighting and want to inspect or view diffs/patches, then you’re in text-editor-like-GUI territory.
Beyond that, there’s viewing and searching logs/history, viewing and managing branches and remotes and generally navigating the history of a repo. Graphical interfaces help with all of that.
A quick example that struck me was viewing the diff between two distant (ie, not adjacent) commits. With a decent GUI, it can be two clicks (with a modifier key). A really nice way of revising the history of a repo especially when there are multiple branches.
There are diff plugins that have syntax highlighting, I use delta for example.
For viewing and searching logs, I prefer the terminal because that’s usually where I am anyway so alt-tabbing to a gui window means more context switching which isn’t a big deal but is enough for me to want to stay in the terminal.
You can just diff two commits on the cli with git diff commit1 commit2 but I guess that what you mean is that you might not have any specific reference two either of the commits so you have to browse through the log to find the commit message that describes the commit, which I’ll grant you is easier in a gui because you have two variables that you have to copy and paste if you’re in the terminal.
The original workflow, which is still in use today, is git-blame followed by git-show: look up candidate commits, then examine their history individually. This can be accelerated with a GUI; e.g. GitHub and GitLab support blame-style views.
You can just diff two commits on the cli with git diff commit1 commit2 but I guess that what you mean is that you might not have any specific reference two either of the commits so you have to browse through the log to find the commit message that describes the commit, which I’ll grant you is easier in a gui because you have two variables that you have to copy and paste if you’re in the terminal.
Yea, this is what I’m talking about. When all of the visual affordances coalesce into a pretty simple flow.
And to be clear, I’d suspect many like myself end up using both, where there’ll always be some shortcoming in any given GUI that only the CLI can fill functionality/power wise. But defaulting to a GUI (or even a good TUI or editor plugin) for everyday usage, like I said, makes sense.
Like you say, there are always gonna be particular cases where gui/cli is better but for the general case I think it has to do with if your workflow is more terminal or gui oriented in general. I think that many of the tradeoffs in gui/cli git aren’t really unique to git so I think sticking with your general preference in that are makes sense.
Since I’m a vim user (shocking, I know) I actually use git through the fugitive plugin a lot, but it’s a fairly thin wrapper around the cli interface so most things are pretty much just the same as using the cli except that you can call them as vim commands instead (:Git push instead of git push and so on)
I must say I like the idea of having changes to files be bound to just the current branch, not the entire worktree (section 6.4.2), but other than that the points that are brought up don’t really seem too compelling. It certainly didn’t convince me that git has an inherently flawed design. For example, eliminating the staging area is a tempting point for simplifying git, but the authors already admit that it has some legitimate use cases.
But of course it is always nice to see some experimentation done in this space. I think the main reason why git sometimes is confusing, is because distributed version control really is a complex task, and git already does a very good job at making it tractable.
Add comment