develooper Front page | perl.perl5.porters | Postings from January 2009

Re: understanding merge history

Thread Previous | Thread Next
Sam Vilain
January 28, 2009 13:50
Re: understanding merge history
Message ID:
On Wed, 2009-01-28 at 09:53 +0100, Rafael Garcia-Suarez wrote: 
> It has two ordering options : --topo-order (the default) and
> --date-order. With --topo-order, IIUC, it will list the children
> commits first, starting with the last branch when there's a merge.
> That is, for your example : F E D2 D1 C3 C2 C1 B A. (With date-order
> it will obviously mix C* and D* commits depending on the timestamps)

These options are somewhat confusingly named.  --date-order is a more
defined version of --topo-order, where it's first topological and then
chronological as a tie breaker.  According to the man page, by default
the commits are shown in reverse chronological order.

> > Now suppose I want to cherry-pick E for maint. It seems to be that
> > if I want all of the branch (ie both D1, and D2), then I just do
> > cherry-pick -m 1 and it applies the diff between C3 and E to maint (ie one
> > big commit containing D1 and D2).
> I don't know, I never cherry-picked a merge... I once reverted a merge,
> and it was a pain. (revert and cherry-pick are very similar operations
> in git)

Cherry-pick is really the wrong tool for dealing with merges.  It only
works with the differences between two adjacent changes, and does a
three-way merge of those differences into the current tree.  You can
specify since git 1.5.4 which parent this is relative to.  But what do
you want a cherry-picked merge to do?  A four-way merge?

If you want to perform a merge and re-use merge resolutions from another
commit, which is about all the sense I can possibly make from the desire
to cherry pick a merge, then the program to use is called git-rerere.
It stores resolution information which is useful for avoiding repeating
merges; I don't know if it can just be pointed at an arbitrary merge and
update its resolution cache from that, but if it's not you can almost
certainly fool it into doing so, with appropriate use of git-reset and
so on.

> > This seems ok as long as the D branch is small and I want all of it.
> > However, what happens if I only want some of the Ds added to maint?
> > Or if I want all the D's, but as individual commits (for better bisecting
> > when things go wrong, for example)?
> I would use git log (or git rev-list) D1..D2 to get the list of SHA1 in
> the branch, and cherry-pick them. There might be some cleverer things to
> do, however.

Yes.  Or you can make a new branch at the end of the D line and use git
rebase -i ... (it takes other arguments to specify where you want to
rebase to) to interactively select which commits you want to try to
rebase to the new place.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About