Version control systems

[Bryan Donlan]

On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree <isaacdupree at charter.net> wrote:

> 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?