On Tue, May 11, 2021 at 5:08 PM Andrew Ottaviano <andrew_o1995@xxxxxxxx> wrote: > > Hello all! > > I’ve used git for a few years now and I > think it is an amazing tool! Thank you for your hard work in > developing/maintaining it! I really appreciate it! > > I have a question. Let’s say that my > colleague and I branch off of master and are working. Let’s say I’m 5 commits > ahead of master and my colleague merges in ahead of me. The logical thing in my > mind is to rebase off of master. 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 could squash, but then I loose branch > history, so I don’t really want to do that. I could rebase in interactive mode, > but if I recall, I still need to resolve all the conflicts on every commit > before it squashes. > > 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. If that doesn’t work (or I guess it might be the same > as a merge of master into my branch), then couldn’t git at least store the > conflict resolution? You might try looking at git imerge for this https://github.com/mhagger/git-imerge It resolves conflicts by doing incremental merges, and then you can have an option to produce the end result of a merge or a rebase. > > Maybe I’m silly for asking this question, > I just really like rebase because it is so clean and this is my one frustration > with this method. > It's definitely a potential frustration that can occur during large rebases like this. Thanks, Jake > > Thanks for humoring me > Andrew Ottaviano
