From: Jacob Keller <jacob.keller@gmail.com>
To: Andrew Ottaviano <andrew_o1995@live.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Rebase Question
Date: Tue, 11 May 2021 17:23:13 -0700 [thread overview]
Message-ID: <CA+P7+xraXVhvjNhJqrzDGNh=RZqC0HnKLBved+7RukC9pmMthQ@mail.gmail.com> (raw)
In-Reply-To: <MN2PR07MB59526F40B255183931649AD19C529@MN2PR07MB5952.namprd07.prod.outlook.com>
On Tue, May 11, 2021 at 5:08 PM Andrew Ottaviano <andrew_o1995@live.com> 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
next prev parent reply other threads:[~2021-05-12 0:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 0:06 Rebase Question Andrew Ottaviano
2021-05-12 0:23 ` Jacob Keller [this message]
2021-05-12 0:29 ` Bryan Turner
2021-05-12 0:44 ` Jeff King
2021-05-12 6:22 ` Junio C Hamano
2021-05-12 7:23 ` Felipe Contreras
-- strict thread matches above, loose matches on Subject: below --
2011-03-11 19:57 rebase question Ryan Sun
2011-03-13 1:05 ` Martin von Zweigbergk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+P7+xraXVhvjNhJqrzDGNh=RZqC0HnKLBved+7RukC9pmMthQ@mail.gmail.com' \
--to=jacob.keller@gmail.com \
--cc=andrew_o1995@live.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.