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) [1] 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 
> [1] 
> http://softwareswirl.blogspot.de/2009/08/git-mercurial-and-bazaarsimplicity.html
> -- 
> Michael Haggerty 
> mha...@alum.mit.edu <javascript:> 
> http://softwareswirl.blogspot.com/ 

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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to