Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does
- From
Sergey Organov <sorganov@gmail.com>
- Date
- Mar 31, 2015, 17:03 UTC
- Message-ID
- <87iodhqetq.fsf@javad.com>
- In-Reply-To
- <xmqqh9t1rv0r.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> Sergey Organov <sorganov@gmail.com> writes: > >> 1. How to calculate the set of commits to rebase. >> >> 2. How to rebase merge commits. >> >> Can we leave (1) for a while at its current state and focus on (2)? > > Perhaps. You would have to be careful though, so let me think aloud > a bit...
Yeah, care should be taken indeed, and it's not trivial to foresee all possible troubles from changing to cherry-picking of merge commits. However, in general it looks like it's better to get some conflict to deal with from cherry-picking than to miss essential changes silently as it sometimes happens now.
I also wonder if git remembers in merge commits what merge strategy was used? If not, then it's yet another argument in favor of cherry-picking.
-- Sergey.