Hi there, Cherry-picking is great with Git, both with git-cherry-pick and git-cherry. I use them to pick commits from my development branch to my stable maintenance branch that goes to production. But when a particular commit is slightly different between the two branches (due to eg a conflict resolution in my stable branch), then git-cherry still lists the commit as only present in the development branch. This is a feature, as documented in the man page, because git-cherry compares the changeset rather than the commit id. So I'm wondering if there's a way to record the commit ID as being already picked from the development branch to the stable branch, so that it's not listed again when I provide the same arguments to cherry-pick. I was used to this kind of feature with svnmerge, a wrapper script around svn that records cherry-picked commits in a Subversion property called svnmerge-integrated on the root directory. But with Git, what is the best practice for knowing which commits you already picked? Ideally, the set of already-picked commits would be versioned in the Git repo itself, so that other developers can watch what commits are available to pick as well. Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/blog/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
