On Wednesday, August 29, 2012 2:21:54 PM UTC+2, Michael Haggerty wrote:
> On 08/28/2012 04:51 PM, Fred wrote:
> > git rev-list ist great, but it doesn't work for cherry picked commits
> > do a cherry-pick commit from branchB into master. git rev-list
> > master..branchB would show sha1 of the commit in branchB.
> > But the change itself is already in master (cherry-picked and has
> > diffrent sha1)
> Git does not keep track of cherry-picked commits in *any* formal way
> (unlike, for example Subversion)  and therefore does not have the
> information required to answer the question that you are asking. This
> is why git workflows are usually organized to avoid the need for
> cherry-picking, for example by always merging forward from old branches
> to new instead of vice versa. In exchange for this limitation, git
> gives much more robust merging and better history visualization tools
> than Subversion.
I agree Git gives me more advantages. That's why I'm using it :)
No one gives a warning about issues with cherry picking or I have missed
it. That said, now I have a problem
> Michael Haggerty
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at