Re: rebase -p loses amended changes

On Thu, Apr 5, 2012 at 6:26 AM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Johannes Sixt [off-list ref] writes:

quoted

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.