Andrew Ottaviano wrote: > The difficulty with this is that if I have merge conflicts that show > up on my first commit, I have to resolve that stupid thing for every > subsequent commit. I don't quite understand that. If you have resolved the chunk, then that chunk is resolved, and the rest of the commits don't have to worry about that... Unless they touch *precisely* the same lines as the first commit, in which case... Yeah, you have to resolve that stupid thing over and over. > The solution that I thought of is instead of resolving conflicts from > the bottom up (starting with earliest history), resolving from the top > down (latest to earliest) and resolving the conflict in the commit it > occurred. Well, this is interesting because it's something I've wanted to write about for a long time, and it's what I call my "pronged approach". I actually do *both*; I do a rebase and fix the problems from 1) the bottom-up, but after I have resolved the conflicts from 2) the top-down. In 1) (bottom-up) I resolve the conflicts in a rebase, and in 2) I resolve the conflicts in merge, but in *both* the end result sould be the exactly same [`git diff 1) 2)` is empty]. Yes, it is more work, but at the end of the day I'm 100% sure I did the rebase right, so I don't have to think about it that much; either there's a diff or there isn't. In fact, I rarely do just one rebase, because quite often I miss things, so I do a second, or third, or fourth rebase, but at the end I make sure that the diff with the merge (top-down approach) is the same. To facilitate this work I use two tools: 1) git rerere [1] (others have mentioned this), and 2) git reintegrate [2] (only useful if there's more than one branch you are merging). Yeah, it's a lot of work, but I'd rather do a lot of tedious work that I'm 100% sure is correct, than do a little bit of work that I can't easily verify. Cheers. [1] https://git-scm.com/docs/git-rerere [2] https://github.com/felipec/git-reintegrate -- Felipe Contreras
