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

Re: understanding merge history

Thread Previous | Thread Next
Rafael Garcia-Suarez
January 28, 2009 00:53
Re: understanding merge history
Message ID:
2009/1/27 Dave Mitchell <>:
> To any git-head out there...
> I'm trying to get my head around some of the implications for history
> and maint, given git's more liberal approach to branching and merging.
> ie in the good ol' Perforce days, the bleed track was a nice simple linear
> thing:
>    A -> B -> C -> D etc
> So, when we updated the Changes file, we would just prepend A,B,C,D to it.
> Similarly, the job of the maint pumpking was to go through the list A, B,
> C and D, and for each, decide whether to reject, apply, or partially apply.
> In the exciting new world of Git, we no longer have a simple linear commit
> history; at the very minimum there are likely to be lots of diamond
> formations, eg
>            C1 -> C2 -> C3
>          /               \
>    A -> B                  E -> F
>          \               /
>            D1 -> D2 ----/
> Where the C's may have been in the bleed branch, and the D's in the y2038k
> branch, for example.
> So, some questions:
> For a merge commit, is there any concept that parent 1 (in the sense of
> git cherry-pick -m 1) is always the 'main' parent - ie always following
> parent 1 will give us a list of of all changes that went into the bleed
> branch rather than all the other temporary branches? ie would it give us:
>    A -> B -> C1 -> C2 -> C3 ->  E -> F

Apart from the order the parents of E are listed, there is no special
distinction between the two lines. If you are on branch foo and issue
"git merge bar" then foo will be the first parent. Which is usually
what happens when you're on blead and merge some feature branch.

> Following on from that, how does git log handle this - ie what subsets of
> C* and D* does it display, and in what order? Any why?

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)

> 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)

> 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.

"You don't mean odds and ends, you mean des curieux et des bouts",
corrected the manager. -- Terry Pratchett, Hogfather

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