Re: rewrite history

From: Jeff King <peff@peff.net>
Date: Jun 16, 2011, 19:49 UTC
Message-ID: <20110616194911.GA14355@sigill.intra.peff.net>
In-Reply-To: <7vhb7ph8aj.fsf@alter.siamese.dyndns.org>

On Thu, Jun 16, 2011 at 12:43:00PM -0700, Junio C Hamano wrote:

Show 23 quoted lines

> >> Hi list. There were 2 branches. One's HEAD was modified to match a
> >> specific commit at another branch. Now, how to merge them according to
> >> this scheme?
> >> 
> >> A---B---X---E---F
> >>                      =>  C---D---X---E---F
> >> C---D---X'
> >> 
> >> X and X' have no difference. I tried to write a script to cherry-pick
> >> E and F, but some of commits are merges and cherry-pick fails.
> >
> > I think you just want to rebase using the "-p" option to preserve
> > merges. Something like:
> >
> >   $ git checkout -b rebased-branch F
> >   $ git rebase -p --onto D B
> >
> > that will pick X, E, and F, and replay them on top of D, resulting in
> > the graph you showed above.
> 
> Eh, careful. Nobody said the change between B and X is any similar to the
> change between D and X'. Replaying the changes E and F introduce on top of
> X' to arrive at C--D--X'-E--F is the best you could do, i.e.

I thought that was exactly what Ilya said with "X and X' have no difference". I assumed that meant "they are semantically similar commits on different bases" (i.e., a cherry-pick) and not "they have the exact same tree state" (i.e., "git diff X X'" is empty).

> But wouldn't filter-branch a better tool for this?  Graft to pretend that
> the parent of X is D instead of B, and filter the branch with F at its
> tip, that is.

If my assumption on the meanings is reversed (i.e., X and X' really are the same tree state, not introducing equivalent commits), then yeah, that would be better.

-Peff