Re: rebase -p loses amended changes
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Apr 4, 2012, 22:55 UTC
- Message-ID
- <CAH3AnrrE9Fbs_p_=ETRns4vyz8J879-m+KDF5K4j7vDdTh9bEg@mail.gmail.com>
- In-Reply-To
- <7viphf8cqh.fsf@alter.siamese.dyndns.org>
On Thu, Apr 5, 2012 at 6:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 29 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > >> Johannes Sixt <j.sixt@viscovery.net> writes: >> >>> IMO, it is a sub-optimal implementation of rebase -p that it attempts to >>> redo the merge. A better strategy is to just replay the changes between >>> the first parent and the merge commit, and then generate a new merge commit: >>> >>> git diff-tree -p M^ M | git apply --index && >>> git rev-parse M^2 > .git/MERGE_HEAD && >>> git commit -c M >>> >>> This would side-step all the issues discussed here, no? >> >> Or cherry-pick the change made by the merge to its first parent, i.e. >> >> git cherry-pick -m 1 M > > Err, that was a confusing unfinished message. I meant the step to replace > the part that uses pipe to "git apply", more like > > git rev-parse M^2 >.git/MERGE_HEAD && > git cherry-pick --no-commit -m 1 M && > git commit -c M > > The primary difference is that, because "apply -3" is not implemented yet, > this will help when the base has drifted too much from the corresponding > blob recorded in M^. >
Ah, not so impossible after all :-).
Yeah, I know, you were talking specifically about the approach suggested in my thought experiment.
It does seem like such an approach would yield an outcome much closer to J Robert Ray's expectation.
Good suggestion, Hannes! Are there any flaws, I wonder?
jon.