Thread (5 messages) flat view 5 messages, 5 authors, 2021-05-12

Re: Rebase Question

From: Jacob Keller <hidden>
Date: 2021-05-12 00:23:27

On Tue, May 11, 2021 at 5:08 PM Andrew Ottaviano [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help