3 ms·

I agree that the concept behind git is powerful and elegant. I very much disagree that the implementation of git is elegant. For example: how many things does `

I agree that the concept behind git is powerful and elegant. I very much disagree that the implementation of git is elegant. For example: how many things does `git checkout` do? And I still don't understand what the point is of having a staging area. Or why I need to edit files in order to provide Git with instructions on what to do when it rebases. Or why adding hunks is so much more difficult than adding complete files. Git is built upon a powerful and beautiful concept, but the Git CLI is just about the worst viable interface to that concept that you can build. There's a reason that there are so many other Git UIs, such as Magit, SourceTree, GitKracken, etc.

ckaygusu 4y ago
In my over 12 years of experience using git, "how many things git checkout do" is still my go-to example to complain about it.
astrange 4y ago
The staging area is so you can get your upcoming commit pretty enough (by adding/removing hunks etc) ahead of time before creating it. If you were previously on SVN where there was no intermediate step between creating a commit and putting it in official server history, I think you'd appreciate all the safety you could get. It does seem like it'd work without it, since there's commit --amend.
Zecc 4y ago
> I still don't understand what the point is of having a staging area. Nor do my coworkers who keep committing whitespace changes and machine-specific configuration changes unrelated to the tasks at hand. For a more serious answer: I find it extremely useful to be able to control what goes exactly into each commit. Sometimes I refactor more than one part of the code at the same time. If one part passes tests and another one doesn't, I can commit just the one that does. If I spot an issue in one part of the codebase and I add a TODO or FIXME in a comment, or if add some logging, or some other inconsequential change, I can leave them in the working copy for later while still adding "atomic" changes to the repo. But by far the most use I get out of it is as a last chance of reviewing the code I just wrote, or as a way of checking the results of an automatic merge before the actual merged commit gets written.
- quanticle 4y ago
  You would still be able to do that without a staging area by having `git commit` take roughly the same arguments as `git add`. So instead of running `git add foo bar baz` followed by `git commit`, you'd just write `git commit foo bar baz`, and it'd launch $EDITOR for the commit message. My understanding is that other distributed version control systems, such as Mercurial or Bazaar, take a similar approach to the above.

ckaygusu 4y ago

In my over 12 years of experience using git, "how many things git checkout do" is still my go-to example to complain about it.

astrange 4y ago

The staging area is so you can get your upcoming commit pretty enough (by adding/removing hunks etc) ahead of time before creating it. If you were previously on SVN where there was no intermediate step between creating a commit and putting it in official server history, I think you'd appreciate all the safety you could get. It does seem like it'd work without it, since there's commit --amend.

Zecc 4y ago

> I still don't understand what the point is of having a staging area. Nor do my coworkers who keep committing whitespace changes and machine-specific configuration changes unrelated to the tasks at hand. For a more serious answer: I find it extremely useful to be able to control what goes exactly into each commit. Sometimes I refactor more than one part of the code at the same time. If one part passes tests and another one doesn't, I can commit just the one that does. If I spot an issue in one part of the codebase and I add a TODO or FIXME in a comment, or if add some logging, or some other inconsequential change, I can leave them in the working copy for later while still adding "atomic" changes to the repo. But by far the most use I get out of it is as a last chance of reviewing the code I just wrote, or as a way of checking the results of an automatic merge before the actual merged commit gets written.

quanticle 4y ago
You would still be able to do that without a staging area by having `git commit` take roughly the same arguments as `git add`. So instead of running `git add foo bar baz` followed by `git commit`, you'd just write `git commit foo bar baz`, and it'd launch $EDITOR for the commit message. My understanding is that other distributed version control systems, such as Mercurial or Bazaar, take a similar approach to the above.