4 ms·
> I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one
by philsnow 7y ago
> I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again.
is this solved by enabling git-rerere ?
https://medium.com/@porteneuve/fix-conflicts-only-once-with-git-rerere-7d116b2cec67 https://medium.com/@porteneuve/fix-conflicts-only-once-with-...
- cryptonector 7y agoNo, it's solved by https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
- StavrosK 7y agoBut it's also solved by merging, which is why I don't see the point of rebasing. What's the advantage?
- cryptonector 7y agoLinear history.
- StavrosK 7y agoHow is that an advantage?
- cryptonector 7y agoIt's much easier to understand linear upstream history! Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.
- StavrosK 7y agoI'll give it a shot next time I have conflicts, thanks.
- cryptonector 7y agoYou're welcome. Leave a comment on the gist about how it goes, if you remember! I'd really like git to have this feature built-in to it...
- StavrosK 7y agoNo :/ I had it enabled, which is why I'm surprised it happened. Unfortunately it was long ago that I don't remember details, but I've had my "merges are much easier" opinion reinforced by git multiple times.