4 ms·

Linear history is nice, but it is lacking the conflict resolutions. They are never committed, and neither are the ”fix rebase” instances. Having a ”fix broken

Linear history is nice, but it is lacking the conflict resolutions. They are never committed, and neither are the ”fix rebase” instances. Having a ”fix broken merge” commit makes it explicit that there was an issue that was fixed. Rebase sometimes seems like an attempt at saving face.

geon 10mo ago
That’s the whole point. You do it properly, so there IS no conflict.
- cluckindan 10mo ago
  No. There is a conflict during a rebase, you resolve it, and then it’s like there never was a conflict. Even if you do it properly, the workflow is erasing history of that conflict existing and needing to be resolved. It leaves no trace of what has been worked on, when, and by whom.
  - geon 10mo ago
    Can you give an example? I think we are talking past each other. This is not my experience at all.
    - cluckindan 10mo ago
      Create new branch A off main. Do some work on a file, commit 1 to branch A. Meanwhile, in another branch B created off main, someone else commits changes to the same part of the same file. That other branch B gets merged to main. Now, rebase branch A onto main. The rebase stops at the commit 1 due to a conflict between main and branch A. Fix the conflict and commit. This erases commit 1 and creates new commit 1' where the conflict has never existed. History has been rewritten. Rebase successfully completes, branch A now contains different commits than previously, so it will need to be force-pushed to remote if it already exists there. The protocol has resistance against changing history. Merge branch A to main. No commit in main now contains any information that there was a conflict that was fixed. Had a pull request workflow been used, the ”merge main to A” merge commit message would detail which files were conflicting. No such commit is made when using a rebase workflow, chasing those clean fast-forward merges.

geon 10mo ago

That’s the whole point. You do it properly, so there IS no conflict.

cluckindan 10mo ago
No. There is a conflict during a rebase, you resolve it, and then it’s like there never was a conflict. Even if you do it properly, the workflow is erasing history of that conflict existing and needing to be resolved. It leaves no trace of what has been worked on, when, and by whom.
- geon 10mo ago
  Can you give an example? I think we are talking past each other. This is not my experience at all.
  - cluckindan 10mo ago
    Create new branch A off main. Do some work on a file, commit 1 to branch A. Meanwhile, in another branch B created off main, someone else commits changes to the same part of the same file. That other branch B gets merged to main. Now, rebase branch A onto main. The rebase stops at the commit 1 due to a conflict between main and branch A. Fix the conflict and commit. This erases commit 1 and creates new commit 1' where the conflict has never existed. History has been rewritten. Rebase successfully completes, branch A now contains different commits than previously, so it will need to be force-pushed to remote if it already exists there. The protocol has resistance against changing history. Merge branch A to main. No commit in main now contains any information that there was a conflict that was fixed. Had a pull request workflow been used, the ”merge main to A” merge commit message would detail which files were conflicting. No such commit is made when using a rebase workflow, chasing those clean fast-forward merges.