6 ms·

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git inter

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty repo or create one from an existing remote repo gl status - show status of the repo gl track - start tracking changes to files gl untrack - stop tracking changes to files gl diff - show changes to files gl commit - record changes in the local repo gl checkout - checkout committed versions of files gl history - show commit history gl branch - list, create, edit or delete branches gl switch - switch branches gl tag - list, create, or delete tags gl merge - merge the divergent changes of one branch onto another gl fuse - fuse the divergent changes of one branch onto another gl resolve - mark files with conflicts as resolved gl publish - publish commits upstream gl remote - list, create, edit or delete remotes To me this clearly demonstrates that the problem isn't that people aren't learning git, it's that git is bad to learn. Stash + Index + Working Tree isn't the right abstraction to present to people. Just say there is a working tree, and tracked and untracked files and snapshots. Done. Branches aren't particular commits but particular working trees on top of particular commits. Working on a feature and want to look at the main branch, but not ready to commit the changes yet? Well just switch to the main branch, then switch back and pick up where you started. No need to know about an additional data structure called the stash. Unfortunately this did not pick up enough steam. And because a lot of tools expose concepts from gits broken interface you have to learn the git interface anyway...

zauguin 5y ago
Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a commit. This has the big advantage that it actually forces the user to add a message what the change is about, so if something else comes up I know what was going on when coming back to it later. It's not like this has to be a formal commit message, after all the commit can be dropped again later. Otherwise you end up being surprised by old experiments when switching to branches you haven't used in a while. If I just switch branches then the most likely reason for that is that I want to move the changes.
- Certhas 5y ago
  Interesting. I haven't met many who have. Your two usecases basically never arose for me. If I switch back to a branch and there's random stuff there, then I can just revert easily. So it's an extra operation at a different time to get there. The other usecase for switching branches temporarily where it's one less command, is more important to me though. The crucial thing though is that both behaviours can be accessed easily but we are dealing with one less data store/stateful thing, because we don't need the stash. As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. I wouldn't claim that gitless is a 100% complete git replacement for expert users. It just shows that git has way too much state exposed to users, and has confusing commands to make that state interact. Obviously we all learned git and use it successfully, so it's obviously not broken or anything, it's just worse than it could be (and the constant chorus of "it's so simple, just a DAG!" is a bit grating if you have to teach beginners regularly). The gitless authors did do some research with users that backs up the claim that this is conceptually easier to use: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf
  - githubalphapapa 5y ago
    > As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. It's not a power-user feature, and it shouldn't be considered one. It should be taught as a standard part of any workflow: before committing, look at the changes you're about to add, and use hunk-staging features (e.g. trivial using Magit) to stage and commit unrelated changes separately. For example, did you clean up some comments and docstrings while you were adding a new feature? Commit those improvements separately, so that if you need to revert the feature commit later, the improvements won't also be reverted. It also makes reviewing much easier, as each commit or patch, having its own purpose, can easily be reviewed separately, and attention can be focused on parts that need changing. > Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. Amending a commit does not serve the same purpose as staging files and hunks separately into the index. It's my impression that few git users understand the value of the index, because few of them use porcelains that expose its power in simple ways. If I had only "git add -p" to use, I might not, either. But Magit is, well, like its name implies, like magic.
cerved 5y ago
personal opinion, if you're a software engineer that can't be bothered to learn git I'm not sure that I respect you as a professional
paulddraper 5y ago
> just demonstrates that the git interface is horribly broken This is HN criticism #94238 on the terrible git CLI. Okay, sure. Would you kindly post your superior git CLI? Or at least the outline of it? --- Snark aside, Git's popularity is not an accident. Bitbucket supported Mercurial too.
- avip 5y ago
  git has quite an inconsistent cli, this is well covered in "master git". And yes, I said it without proposing a better one.
  - paulddraper 5y ago
    "master git" This is a great demonstration of git's inconsistencies. I maintain git stacks up well against other similarly mature/complex software (Nginx, AWS, Java), but it's a wonderful read nonetheless. (And holy hell what a hard thing to search for...can't find the link.)
    - avip 5y ago
      https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/ The trick is to remember it's called "git koans"
      - paulddraper 5y ago
        Thanks.
- seoaeu 5y ago
  > Would you kindly post your superior git CLI? Or at least the outline of it? You are literally replying to a comment that describes a possible better CLI for git...
  - kjeetgill 5y ago
    I suspect it was added in an edit in response to this comment. Dad is downvoted!
antman 5y ago
gl merge - merge the divergent changes of one branch onto another gl fuse - fuse the divergent changes of one branch onto another Good while it lasted though
- spinitch 5y ago
  Yup. That was exactly the point at which the commenter's promise of "just look at a summary of the commands, you will have an accurate mental model of what's going on" break down for me.
tharkun__ 5y ago
In the same vein as my sibling but not repeating what he said I agree with him though, I regularly commit just specific files. I actually teach every GUI I use that comes with git integration NOT to Auto add and such nuisances. I use the command line and in probably 90% of cases a git commit -a is what I do. Another 5 is git add the entire directory tree I am in and the other 5 are specifically picking what to commit. I'm all for UIs doing auto add and commit -a equivalent by default. But do not take that ability away from me! The list you provide sounded great until it came to gl switch. Why is there one specific operation for a branch that is NOT done via gl branch? I don't understand what fuse is supposed to do from this at all. No idea whatsoever. Merge I get and anyone who has worked with any other versioning tool does conceptually. Rebase most people seem to have a problem with but the abstract concept really isn't that hard. Just like cherry pick isn't really hard but somehow people have trouble with it. Though conceptually it really isn't hard either. What really helped me the most with git was the realization that it's just a tree of commits with a bunch of labels. Labels have different types so to speak, like branch or tag, remote branches being special in a way etc. And obviously various commands can interact with these labels. Like a fetch updates the remote labels and moves them around on my local copy.
- Certhas 5y ago
  Did you actually look at the page the list is from? THis isn't some sketch, it's a fully implemented way of working with git repos that supports everything you ask for. Committing just specific files is done in gitless via gl commit a.foo b.bar committing all but some files is done with gl commit -e a.foo b.bar gl commit -p allows you to interactively commit parts of files. gl doesn't take any abilities away (it's just git under the hood after all), it just exposes the abilities in sane ways. If you actually look at the homepage of gitless you will also immediately see what fuse does: https://gitless.com/#gl-fuse https://gitless.com/#gl-fuse I believe that by reading that one, not very long page, most people (including non-programmers) can use gl correctly most of the time. This is not the case for git. BTW, gl branch is for creating/deleting branches, gl switch is for switching your working tree from one branch to another. These are very different things, why should they be under the same command? For git, the last paragraph is a necessary but in no way sufficient step towards using it proficiently. Gitless is actually much closer to realizing that vision. Seriously, people need to go back and teach beginners git to realize how bad it is. We have internalized so much of the bad design decisions in git that we don't notice them anymore.
lmm 5y ago
I hate the inconsistency that stash brings, but gitless is useless since it destroys the primary use case for stashing: I start making changes and then realise I'm working on the wrong branch. Git's solution to the problem is awful, but it's better than nothing.

zauguin 5y ago

Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a commit. This has the big advantage that it actually forces the user to add a message what the change is about, so if something else comes up I know what was going on when coming back to it later. It's not like this has to be a formal commit message, after all the commit can be dropped again later. Otherwise you end up being surprised by old experiments when switching to branches you haven't used in a while. If I just switch branches then the most likely reason for that is that I want to move the changes.

Certhas 5y ago
Interesting. I haven't met many who have. Your two usecases basically never arose for me. If I switch back to a branch and there's random stuff there, then I can just revert easily. So it's an extra operation at a different time to get there. The other usecase for switching branches temporarily where it's one less command, is more important to me though. The crucial thing though is that both behaviours can be accessed easily but we are dealing with one less data store/stateful thing, because we don't need the stash. As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. I wouldn't claim that gitless is a 100% complete git replacement for expert users. It just shows that git has way too much state exposed to users, and has confusing commands to make that state interact. Obviously we all learned git and use it successfully, so it's obviously not broken or anything, it's just worse than it could be (and the constant chorus of "it's so simple, just a DAG!" is a bit grating if you have to teach beginners regularly). The gitless authors did do some research with users that backs up the claim that this is conceptually easier to use: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf
- githubalphapapa 5y ago
  > As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. It's not a power-user feature, and it shouldn't be considered one. It should be taught as a standard part of any workflow: before committing, look at the changes you're about to add, and use hunk-staging features (e.g. trivial using Magit) to stage and commit unrelated changes separately. For example, did you clean up some comments and docstrings while you were adding a new feature? Commit those improvements separately, so that if you need to revert the feature commit later, the improvements won't also be reverted. It also makes reviewing much easier, as each commit or patch, having its own purpose, can easily be reviewed separately, and attention can be focused on parts that need changing. > Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. Amending a commit does not serve the same purpose as staging files and hunks separately into the index. It's my impression that few git users understand the value of the index, because few of them use porcelains that expose its power in simple ways. If I had only "git add -p" to use, I might not, either. But Magit is, well, like its name implies, like magic.

cerved 5y ago

personal opinion, if you're a software engineer that can't be bothered to learn git I'm not sure that I respect you as a professional

paulddraper 5y ago

> just demonstrates that the git interface is horribly broken This is HN criticism #94238 on the terrible git CLI. Okay, sure. Would you kindly post your superior git CLI? Or at least the outline of it? --- Snark aside, Git's popularity is not an accident. Bitbucket supported Mercurial too.

avip 5y ago
git has quite an inconsistent cli, this is well covered in "master git". And yes, I said it without proposing a better one.
- paulddraper 5y ago
  "master git" This is a great demonstration of git's inconsistencies. I maintain git stacks up well against other similarly mature/complex software (Nginx, AWS, Java), but it's a wonderful read nonetheless. (And holy hell what a hard thing to search for...can't find the link.)
  - avip 5y ago
    https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/ The trick is to remember it's called "git koans"
    - paulddraper 5y ago
      Thanks.
seoaeu 5y ago
> Would you kindly post your superior git CLI? Or at least the outline of it? You are literally replying to a comment that describes a possible better CLI for git...
- kjeetgill 5y ago
  I suspect it was added in an edit in response to this comment. Dad is downvoted!

antman 5y ago

gl merge - merge the divergent changes of one branch onto another gl fuse - fuse the divergent changes of one branch onto another Good while it lasted though

spinitch 5y ago
Yup. That was exactly the point at which the commenter's promise of "just look at a summary of the commands, you will have an accurate mental model of what's going on" break down for me.

tharkun__ 5y ago

In the same vein as my sibling but not repeating what he said I agree with him though, I regularly commit just specific files. I actually teach every GUI I use that comes with git integration NOT to Auto add and such nuisances. I use the command line and in probably 90% of cases a git commit -a is what I do. Another 5 is git add the entire directory tree I am in and the other 5 are specifically picking what to commit. I'm all for UIs doing auto add and commit -a equivalent by default. But do not take that ability away from me! The list you provide sounded great until it came to gl switch. Why is there one specific operation for a branch that is NOT done via gl branch? I don't understand what fuse is supposed to do from this at all. No idea whatsoever. Merge I get and anyone who has worked with any other versioning tool does conceptually. Rebase most people seem to have a problem with but the abstract concept really isn't that hard. Just like cherry pick isn't really hard but somehow people have trouble with it. Though conceptually it really isn't hard either. What really helped me the most with git was the realization that it's just a tree of commits with a bunch of labels. Labels have different types so to speak, like branch or tag, remote branches being special in a way etc. And obviously various commands can interact with these labels. Like a fetch updates the remote labels and moves them around on my local copy.

Certhas 5y ago
Did you actually look at the page the list is from? THis isn't some sketch, it's a fully implemented way of working with git repos that supports everything you ask for. Committing just specific files is done in gitless via gl commit a.foo b.bar committing all but some files is done with gl commit -e a.foo b.bar gl commit -p allows you to interactively commit parts of files. gl doesn't take any abilities away (it's just git under the hood after all), it just exposes the abilities in sane ways. If you actually look at the homepage of gitless you will also immediately see what fuse does: https://gitless.com/#gl-fuse https://gitless.com/#gl-fuse I believe that by reading that one, not very long page, most people (including non-programmers) can use gl correctly most of the time. This is not the case for git. BTW, gl branch is for creating/deleting branches, gl switch is for switching your working tree from one branch to another. These are very different things, why should they be under the same command? For git, the last paragraph is a necessary but in no way sufficient step towards using it proficiently. Gitless is actually much closer to realizing that vision. Seriously, people need to go back and teach beginners git to realize how bad it is. We have internalized so much of the bad design decisions in git that we don't notice them anymore.

lmm 5y ago

I hate the inconsistency that stash brings, but gitless is useless since it destroys the primary use case for stashing: I start making changes and then realise I'm working on the wrong branch. Git's solution to the problem is awful, but it's better than nothing.