Hacker News new | past | comments | ask | show | jobs | submit login

> 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-...




No :/ 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.



But it's also solved by merging, which is why I don't see the point of rebasing. What's the advantage?


Linear history.


How is that an advantage?


It'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.


I'll give it a shot next time I have conflicts, thanks.


You'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...




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: