Flight rules for Git

Re:Flight rules for Git by masklinn on Tuesday October 16, 2018 @12:29PM (#18230698)

Bullshit. The "mental model" has never been the issue with git, it's always been that the UI is garbage and a giant abstraction leak, requiring knowing the implementation details of the commands and the storage model to work with and step over footguns. Because rather than an actual, designed, considered UI, the porcelain is crummy shortcuts on sets of operations on the underlying storage (not mental) model.

Mercurial has the same "DAG of revisions" model as git, and works just fine, because it has a good UI.

Darcs has a more unusual mental model than git, and works just fine, because it has a good UI.

[ Parent | on HN ]

Re:Flight rules for Git by jgraham on Tuesday October 16, 2018 @01:29PM (#18231293)

> Mercurial has the same "DAG of revisions" model as git, and works just fine, because it has a good UI.

People keep saying this, and this keeps not matching my experience of helping people with VCS issues at Mozilla.

Mercurial's model is roughly "append only list of commits, that separately form a DAG". This list model is leaked all over the place. For example the default `hg log` view just dumps that list rather than telling you anything about the history of the current working copy. To get that you need to add -f, which of course in most contexts means "do something unsafe". Worse, the list model is exposed in the local revision ids, which are prominently presented in the UI, and users have to learn that these ids aren't sharable with other users when discussing a revision. Also the most prominent "symbolic ref" in mercurial is "tip" which means "commit at the last position in the internal list", and so is sometimes the current head, and other times is some random commit from the remote.

Giving people help in mercurial is also super-challenging because, unless you are in some controlled environment, the first question is always "which extensions do you have enabled" and for complex tasks the next step is often "you should enable and learn to use <some extension>".

Which isn't to say that Mercurial is overall particuarly bad. There are some areas in which it's really an improvement over git (revset specifiers are pretty awesome, for example). But I often feel like praise for the UI comes from people who have internalised its flaws, and is repeated by people who haven't actually used it, but dislike git and are happy to accept something that confirms their preconceptions.

[ Parent | on HN ]

Re:Flight rules for Git by meuk on Tuesday October 16, 2018 @02:40PM (#18231997)

The biggest leaking abstraction of git IMO, are commits: they equate a set of changes with the state of the repo after said changes. So if there are multiple commits, reverting a commit is ambiguous. Does it revert the state of the repository to the state before the commit, or does it revert the changes in the commit?

There are a couple more flaws. The commandline is not very consistent, and the complete model is way too complicated IMHO. I can work with it now, but it took me a long time to grasp all of the concepts that I need - without feeling the need for distibuted version control. About that: It's kind of ironic that git is hailed for being distributed, but everyone just uses github, a centralized system.

[ Parent | on HN ]

Re:Flight rules for Git by cesarb on Tuesday October 16, 2018 @02:57PM (#18232138)

Just to be pedantic, a commit is actually "the state of the repo after said changes" plus "the commit(s) before said changes" (which allows one to recover the "set of changes" by comparing the before/after states).

[ Parent | on HN ]

Re:Flight rules for Git by meuk on Tuesday October 16, 2018 @03:07PM (#18232211)

I don't think that's true. At least, not if you revert something - it reverts only the changes introduced in that commit. (That there is confusion - or even discussion possible - is exactly my point: the abstraction is leaky at worst, and confusing at best).

Edit: You're right, but my point was that the revert command treats a commit like a set of changes, not like the state of of a repo (since you can't revert the state of a repo, but you can revert changes).

[ Parent | on HN ]

Re:Flight rules for Git by cesarb on Tuesday October 16, 2018 @03:30PM (#18232423)

See for yourself: do a "git cat-file commit HEAD" on any repository. The "tree" line is the current state, the "parent" line(s) are the preceding commit(s). That command shows everything git has recorded for any commit (you can similarly use "git ls-tree <sha1>" to show everything git has recorded for any tree, or "git cat-file blob <sha1>" to show the contents of a file from the tree).

[ Parent | on HN ]

Re:Flight rules for Git by meuk on Tuesday October 16, 2018 @03:48PM (#18232578)

You're right from a technical perspective. What I meant that as an abstraction, it serves a double purpose (it represents both a node and an edge in the DAG, and it depends on the command that you use which interpretation is right).

If you checkout a commit, the commit represents the state of the repository. If you revert a commit, the commit represents a set of changes.

[ Parent | on HN ]