3 ms·

> Git puts a lot of emphasis on maintaining a "clean" check-in history. This seems like an inaccurate phrasing of this. Git (the tool) doesn't specifically emp

by joshka 8y ago

> Git puts a lot of emphasis on maintaining a "clean" check-in history. This seems like an inaccurate phrasing of this. Git (the tool) doesn't specifically emphasize this, but it does support this as a possible approach without excluding the other approach. Many teams have settled on development approaches with git that do indeed emphasize this, but not every team does. If you want to show your work, you sure can, but unlike fossil, git does not force this upon developers. Like the article, I don't see either approach as right or wrong, but know that I prefer the clean history approach rather than every typo commit ever.

pseudalopex 8y ago
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.
cryptonector 8y ago
See, if you get a choice, at least you got the choice. When you get no choice in the matter, then the tool is opinionated, and forces its developers' choices on you. Sometimes that's nice, but mostly that's when you can live with those choices. Clean, linear history is absolutely the best choice for any sufficiently large project, and never the wrong choice for small projects, so being forced to do merge workflows is really suboptimal.

by joshka 8y ago

pseudalopex 8y ago

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.

cryptonector 8y ago

See, if you get a choice, at least you got the choice. When you get no choice in the matter, then the tool is opinionated, and forces its developers' choices on you. Sometimes that's nice, but mostly that's when you can live with those choices. Clean, linear history is absolutely the best choice for any sufficiently large project, and never the wrong choice for small projects, so being forced to do merge workflows is really suboptimal.