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 https://groups.google.com/d/msg/git-users/-/RaFRaKti0csJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
