On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree
And I wonder why (it sounds like) Git doesn't have tools to do some kind of smart cherrypicking, using a heuristic to decide which patches in a branch are definitely dependencies of the cherry-picked patch. In any case, I notice a few times with ghc/darcs/Trac tickets, more than one commit has to be listed explicitly to be merged into the stable branch. Maybe it's not very useful/reliable for these purposes anyway?
The intent with git is that you would do such cherrypicks at the branch level, not at the individual commit level - ie, if you have dependent patches that also need to be backported or whatever, you really ought to have developed the feature as a branch in the first place. You could then rebase such a branch to a prior version, and merge it into both old and new; or you could just rebase it on top of wherever you're backporting to, if you don't intend to do big merges much between the two (as the commit IDs would be different in this case). You can of course just use git cherry-pick, but this doesn't have any intelligence at all when it comes to avoiding duplicate patches - it basically just diffs from the old commit and applies it somewhere else. The git merging logic does have some heuristics to detect duplicate patches and do the right thing, however. The limitations come from git's relatively simple history model, in which commits have parent commits but no 'sideways' relationships. In practice I don't think it will be a problem - how often will there be branches which will receive cherry picks and then later have a merge from or to the same source?