10 ms·
You have to fix conflicts either way so what's the difference? I suppose when merging you only have to fix the cumulative conflicts, while when rebasing you hav
by ahelwer 3y ago
You have to fix conflicts either way so what's the difference? I suppose when merging you only have to fix the cumulative conflicts, while when rebasing you have to incrementally fix the conflicts introduced by every commit which is annoying. I usually squash a branch (rebase on where it diverged) before rebasing to fix this.
- halostatue 3y agoIt’s worth configuring rerere (reuse recorded resolution): https://git-scm.com/docs/git-rerere https://git-scm.com/docs/git-rerere for merges and rebases, because repeated rebases or merges of similar code will become substantially easier.
- frutiger 3y ago> revere Innocent typo but for anyone else reading, it’s “rerere”.
- halostatue 3y agoThanks. I still had time to fix it, so I’ve corrected it. I had typed rerere, but autocorrect "fixed" it for me whether I wanted it fixed or not.
- adontz 3y agoAfter rebasing you basically have two versions of the same commit, and that is the root of the problem.
- unmole 3y ago> After rebasing you basically have two versions of the same commit, and that is the root of the problem. No, you have two commits. Git commits are snapshots, not diffs. Git's data model is simple. The fact that people do not bother trying to understand it is the root of the problem.
- adontz 3y agoI never stated otherwise, IDK what are you not agreeing with.
- p1esk 3y agoWhy is this downvoted?