Re: git cherry-pick --strategy=resolve segfaults if picking a root commit

From: Jeff King <peff@peff.net>
Date: May 12, 2011, 11:08 UTC
Message-ID: <20110512110855.GA5240@sigill.intra.peff.net>
In-Reply-To: <20110512104558.GA22108@sigill.intra.peff.net>

On Thu, May 12, 2011 at 06:45:58AM -0400, Jeff King wrote:

Show 12 quoted lines

> So probably we should:
> 
>   1. Pass the empty tree along to merge-resolve. This will take a little
>      bit of refactoring, but more importantly, it means we will be
>      passing a tree-ish and not a commit-ish to a merge strategy. Is
>      that OK?
> 
>   2. Consider lifting the restriction on reverting root commits. If we
>      can cherry-pick it, we can revert it, so I suspect this would
>      already work with merge-recursive, but I didn't try. I don't care
>      too much either way, though; I doubt it's something people would do
>      a lot. It just seems like an unnecessary restriction.

This turned out to be quite easy. git-merge-resolve handles the tree-ish argument just fine. But it's possible other merge helpers might not be so happy. I dunno.

The series is:

  [1/3]: cherry-pick: handle root commits with external strategies
  [2/3]: revert: allow reverting a root commit
  [3/3]: t3503: test cherry picking and reverting root commits

-Peff