Re: git tag --contains for cherry-picks

From: Jakub Narębski <jnareb@gmail.com>
Date: Jun 30, 2016, 10:41 UTC
Message-ID: <5774F747.4000700@gmail.com>
In-Reply-To: <20160630062236.GA15380@sigill.intra.peff.net>

W dniu 2016-06-30 o 08:22, Jeff King pisze:

Show 22 quoted lines

> On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:
> 
>> Old releases are maintained with important bug fixes or even new features
>> in our case. It sometimes means that we need to cherry-pick commits across
>> branches, like from master to a specific release branch.
>>
>> Cherry-picking changes the hash of the commit, therefore, this may no
>> longer work for cherry-picks:
>>
>> git tag --contains
>>
>> I am thinking of having something like:
>>
>> git tag --contains-follow
>>
>> which would follow cherry-picks. I am not sure how easily and/or
>> efficiently this can be implemented, but my gut feeling is that in the vast
>> majority of the cases, the content check would bail out already at the
>> "subject line".
> 
> Git generally considers commits "equivalent" based on the patch-id, whic
> his a sha1 of the diff (modulo some canonicalization).

The problem with patch based equivalence is that for cherry-picking on old release branches you might need to modify a patch for it to apply - and then patch-id might not detect it.

[...]

Show 6 quoted lines

> Of course there are other ways of determining commit equivalence. You
> could find ones with duplicate commit messages, or duplicate subjects,
> or whatever. But if you have a cherry-picking workflow, I suspect the
> easiest thing may be to simply use "git cherry-pick -x", which will
> write the sha1 of the original commit into the cherry-picked commit
> message. You can then use that to correlate directly.

"git log --grep=<sha-1>" would help there (or even match the specific message that "git cherry-pick -x" adds).

-- 
Jakub Narębski