6 ms·

It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. Ever sat through user tra

It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. Ever sat through user training on microsoft office? How to use email? The weird one-off enterprise apps that nobody else has ever heard of? They’re unbearably tedious to users that can get by in a new tool with a 5 minute crash course, intuition and light googling. Then git shows up and has the audacity to ask professionals to learn its mental model. Once you do the interface isn’t great, but not particularly esoteric. The problem isn’t that users see dense-sounding things like “directed acyclic graph of revisions”, it’s that they assume they can competently manipulate one without knowing what that means. I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git?

tome 8y ago
> I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git? Git's interface is far, far more complicated than its model. Personally I spent years not learning about the model because I thought it would be as complicated as the interface. When I realised that the model is basically as simple as what you get when you view the "network" on GitHub then I started loving Git.
- seba_dos1 8y ago
  Exactly this. Git is pretty easy; at the same time, using Git isn't. If you skip learning the easy mental model, all you have left is hard interface, so in result you just struggle, because you can't even rely on your intuition to get how things work there.
- amag 8y ago
  I've found that adding my own aliases that sound more akin to what I'm trying to achieve has helped greatly with this, e.g. I have 'discard' as an alias for 'checkout --'.
masklinn 8y ago
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.
- jgraham 8y ago
  > 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.
- meuk 8y ago
  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.
wild_preference 8y ago
> It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. It's fun to be cynical, but surely this is just yet another example of how hard it is to "just change" something for all sorts of reasons. It's funny that you bring up hubris when the pinnacle of developer hubris is "surely it can't be too hard to {build it, change it, replace it} -- I could do it!"
kurtisc 8y ago
Conversely, no other industry places so much focus on making sure that tools for professionals are easy for beginners to use, often at the expense of features.

tome 8y ago

> I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git? Git's interface is far, far more complicated than its model. Personally I spent years not learning about the model because I thought it would be as complicated as the interface. When I realised that the model is basically as simple as what you get when you view the "network" on GitHub then I started loving Git.

seba_dos1 8y ago
Exactly this. Git is pretty easy; at the same time, using Git isn't. If you skip learning the easy mental model, all you have left is hard interface, so in result you just struggle, because you can't even rely on your intuition to get how things work there.
amag 8y ago
I've found that adding my own aliases that sound more akin to what I'm trying to achieve has helped greatly with this, e.g. I have 'discard' as an alias for 'checkout --'.

masklinn 8y ago

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.

jgraham 8y ago
> 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.
meuk 8y ago
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.

wild_preference 8y ago

> It’s basically a manifestation of programmer arrogance that they’re just too damn smart to encounter a software learning curve again. It's fun to be cynical, but surely this is just yet another example of how hard it is to "just change" something for all sorts of reasons. It's funny that you bring up hubris when the pinnacle of developer hubris is "surely it can't be too hard to {build it, change it, replace it} -- I could do it!"

kurtisc 8y ago

Conversely, no other industry places so much focus on making sure that tools for professionals are easy for beginners to use, often at the expense of features.