3 ms·

I had a detailed discussion with a former colleague about this the other day. They're in the merge camp, and I'm in the "any code that actually makes it into t

I had a detailed discussion with a former colleague about this the other day. They're in the merge camp, and I'm in the "any code that actually makes it into the wild should have a linear history" (rebase) camp. Merge commits have multiple parents which makes visual inspection confusing, and it makes it much harder to use git bisect which is a tool that can save many hours of painstaking manual work. I clearly think that the rebase version is the correct approach, but I can see there are upsides and downsides for both. Sometimes for long lived branches I get merge commits in my feature / bugfix branches, but those are going to end up squash merged onto our release branch, so in the end the main thing I care about is the linearity of history in master/develop. Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). A merge based approach shows you what people were actually doing though.

naasking 3y ago
I'll leave this here for you to peruse: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md > Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.
- singingfish 3y ago
  If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. If your history is linear, and your data model is compatible with itself across history for the bits you're interested in, and you can write a sane test case - auto or manual, then your troubleshooting is going to be O(n^x) simpler than the case where you've got merge commits, and save you many hours. Not something I have to do often (once a year or less really) but valuabable enough that it's important to me nonetheless. Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner. At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing. I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration. Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches). I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.
  - naasking 3y ago
    Gotta say, in 20+ years of branching and merging using CVS, SVN and then Mercurial, I've never had an issue tracking down nasty bugs. Maybe git bisect on a linear history would hypothetically be a few minutes faster in some cases, but doesn't make it worth all of the extra work and the dangers of overwriting other people's work. I think the Fossil devs also make a good case that the problem is really a limitation in the tools like git bisect.
- baq 3y ago
  Intentionality is the perfect argument against merging feature branches: I intentionally don’t want my half-broken commits to be in the production branch. I want the complete product to be there.
  - naasking 3y ago
    > I intentionally don’t want my half-broken commits to be in the production branch. That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.
    - singingfish 3y ago
      The whole argument feels a bit People's Liberation Front of Judea to me. On the other hand I do have strong views on the matter, and I am pretty certain that my views are pretty close to the correct ones.
    - baq 3y ago
      My silly aesthetic restriction is ‘tests pass’ and my branch commits don’t have this quality in all cases.
  - IlliOnato 3y ago
    Apparently what you do makes sense for you, but I hope you realize that using interactive rebase you can turn your half-broken commits into nice and clean commits! I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging. Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws. Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.

naasking 3y ago

I'll leave this here for you to peruse: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md > Combination of linear history and appropriate use of annotated tags for releases makes it way easier to see what actually happened (i.e. the intentionality). I still haven't heard a good reason why linear history using git as an archaeological tool is the appropriate method to "infer intent". It seems like you would only have to infer intent this way if you have poor development practices, like not adding appropriate comments and not tying important changes to tickets that provide more background/context.

singingfish 3y ago
If you have a nasty nasty difficult to find bug that emerged some time ago, and your history is littered with merge commits, git bisect is going to go badly. If your history is linear, and your data model is compatible with itself across history for the bits you're interested in, and you can write a sane test case - auto or manual, then your troubleshooting is going to be O(n^x) simpler than the case where you've got merge commits, and save you many hours. Not something I have to do often (once a year or less really) but valuabable enough that it's important to me nonetheless. Rewriting history when things land in develop/master I think is a good thing. To use an analogy from the humanities, history is written by the winner. At work we're collaborating with the merge camp at the moment and it's very difficult to work out what they're doing from reading their history - some of it is their bad practices elsewhere, but the merge commits are confusing. I'd also be fine with no rebasing but any merges must be fast forward, so if you can't do that fix your problems prior to integration. Also I've used a few different approaches for a few different projects, and the rebase/squash merge approach is the one that in my experience makes things clearer and easier to understand. I'd be reluctant to return to other approaches (aside from enforcing fast forward merges in public branches). I believe that squash merges are a good compromise as so long as you don't mess with the reflog and keep the automated parts of the commit messages, then there is no lying about history.
- naasking 3y ago
  Gotta say, in 20+ years of branching and merging using CVS, SVN and then Mercurial, I've never had an issue tracking down nasty bugs. Maybe git bisect on a linear history would hypothetically be a few minutes faster in some cases, but doesn't make it worth all of the extra work and the dangers of overwriting other people's work. I think the Fossil devs also make a good case that the problem is really a limitation in the tools like git bisect.
baq 3y ago
Intentionality is the perfect argument against merging feature branches: I intentionally don’t want my half-broken commits to be in the production branch. I want the complete product to be there.
- naasking 3y ago
  > I intentionally don’t want my half-broken commits to be in the production branch. That makes no sense. What does it matter that interim versions from a merge might not work, what matters are the milestones like merges and tags. Basically you're imposing a silly aesthetic restriction on what's supposed to be a functional tool.
  - singingfish 3y ago
    The whole argument feels a bit People's Liberation Front of Judea to me. On the other hand I do have strong views on the matter, and I am pretty certain that my views are pretty close to the correct ones.
  - baq 3y ago
    My silly aesthetic restriction is ‘tests pass’ and my branch commits don’t have this quality in all cases.
- IlliOnato 3y ago
  Apparently what you do makes sense for you, but I hope you realize that using interactive rebase you can turn your half-broken commits into nice and clean commits! I try to do this as I go, but there is always a "history review and fix if necessary" stage after I've got the code I wanted and before merging. Apart from having granular, reviewable, bisectable history, there were many a time when by having this extra look at the code I found bugs or design flaws. Whether such effort is worth it for you, and whether you have time\energy\discipline\skills for it is a different question.