4 ms·

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqu

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqusahed commits.

cryptonector 8y ago
Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.
- pseudalopex 8y ago
  If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
  - cryptonector 8y ago
    Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.
joshka 8y ago
I use the following fairly regularly (aliased): git log --graph --oneline I can understand how you could see this as an advantage, but I see forcing this on the developer as more of a disadvantage. I literally never want to see in any history commits with junk attempts to fix something. After the fact, these are the least interesting things to me.
- pseudalopex 8y ago
  That doesn't keep the branch names. It also doesn't help bisect complex merges. Git may be better at that now, to be fair. So many projects rebase or squash that I haven't had to do it in a while. Mercurial can rewrite history in the same ways as Git. I never want to see junk commits, but I can't force other people to spend time cleaning them up. Squashing cleans them up quickly but loses useful information.

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqusahed commits.

cryptonector 8y ago

Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.

pseudalopex 8y ago
If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
- cryptonector 8y ago
  Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.

joshka 8y ago

I use the following fairly regularly (aliased): git log --graph --oneline I can understand how you could see this as an advantage, but I see forcing this on the developer as more of a disadvantage. I literally never want to see in any history commits with junk attempts to fix something. After the fact, these are the least interesting things to me.

pseudalopex 8y ago
That doesn't keep the branch names. It also doesn't help bisect complex merges. Git may be better at that now, to be fair. So many projects rebase or squash that I haven't had to do it in a while. Mercurial can rewrite history in the same ways as Git. I never want to see junk commits, but I can't force other people to spend time cleaning them up. Squashing cleans them up quickly but loses useful information.