4 ms·

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encoura

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many other folks have figured out decent ways to use it effectively as well but don't mistake that for Git being an unquestionably good tool or for it being "easy". Sure, the core workflow is pretty straightforward, but the fact that the easy stuff is easy is not a ringing endorsement of a tool. Good tools make hard stuff easier and easy stuff trivial. Make no mistake, I think there are lots of awesome parts of git, the most important being its distributed nature. It's trivial to setup a repository because everything is a repository. That's pretty potent, and git has some reasonably well engineered components inside of it which make it fast for many common use cases, which is fantastic. But a big part of why git has been so successful lately has been because it hasn't had a lot of competition. Much of the competition is either hugely expensive (perforce, TFS), doesn't match the use case (same), hugely outdated (SVN), or terrible (TFS). The main competition for git is Mercurial, and a big reason git won out over Hg is because of mindshare traction and network effect from linux kernel development and then github. The biggest problem now is that so many git fans are afraid of criticizing git's shortcomings.

sofal 12y ago
just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world? Now if you're just talking about rewriting published history, then nobody is going to disagree with you.
- jotux 12y ago
  I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.
  - jfb 12y ago
    Exactly this. I get all the benefits of a DVCS, pushing and pulling from my private fork, distributing development between my home and office machines, never losing changes; and then when I'm ready to publish, I can go back and rationalize my commits (many of which are "git commit -am 'oh sbt'" sorts of things) into a useful history and issue a PR for the rest of the team to code review. It's taken me a while to come around, but you'd have to pry rebase out of my cold dead hands now.
- avar 12y ago
  What people are really saying when they say you shouldn't write history is that your SCM shouldn't support work in progress checkins. Not supporting that just makes your SCM inflexible.
- antientropic 12y ago
  Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased and did make sense originally.)
  - sofal 12y ago
    If they're rewriting published history, it's even worse than that, because it could change history that you are currently developing on top of, requiring some more advanced git knowledge to get your local repository into a correct state. I have not found it to happen often though, for two reasons. First, it is widely agreed upon among almost all mildly experienced to highly experienced Git users that rewriting published history is a bad thing. Second, if it becomes a problem with new Git users doing this, you can turn of non-ff updates in the public repository, thereby disallowing this to ever happen, unless you go through all the steps to delete and recreate a branch. If you're working with your local unpublished history, then it is your responsibility to make sure they still make sense in the context of newer updates from the public repo regardless of whether you rebase or merge. I can see how it would be confusing if people failed at this. I tend to find that more confusion results from people inflating the history with loads of one-commit merge bubbles everywhere rather than just rebasing their small changes.

sofal 12y ago

just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world? Now if you're just talking about rewriting published history, then nobody is going to disagree with you.

jotux 12y ago
I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.
- jfb 12y ago
  Exactly this. I get all the benefits of a DVCS, pushing and pulling from my private fork, distributing development between my home and office machines, never losing changes; and then when I'm ready to publish, I can go back and rationalize my commits (many of which are "git commit -am 'oh sbt'" sorts of things) into a useful history and issue a PR for the rest of the team to code review. It's taken me a while to come around, but you'd have to pry rebase out of my cold dead hands now.
avar 12y ago
What people are really saying when they say you shouldn't write history is that your SCM shouldn't support work in progress checkins. Not supporting that just makes your SCM inflexible.
antientropic 12y ago
Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased and did make sense originally.)
- sofal 12y ago
  If they're rewriting published history, it's even worse than that, because it could change history that you are currently developing on top of, requiring some more advanced git knowledge to get your local repository into a correct state. I have not found it to happen often though, for two reasons. First, it is widely agreed upon among almost all mildly experienced to highly experienced Git users that rewriting published history is a bad thing. Second, if it becomes a problem with new Git users doing this, you can turn of non-ff updates in the public repository, thereby disallowing this to ever happen, unless you go through all the steps to delete and recreate a branch. If you're working with your local unpublished history, then it is your responsibility to make sure they still make sense in the context of newer updates from the public repo regardless of whether you rebase or merge. I can see how it would be confusing if people failed at this. I tend to find that more confusion results from people inflating the history with loads of one-commit merge bubbles everywhere rather than just rebasing their small changes.