On Jun 21 2016, Junio C Hamano <gits...@pobox.com> wrote:
> Nikolaus Rath <nikol...@rath.org> writes:
>
>> On Jun 20 2016, Nikolaus Rath <nikol...@rath.org> wrote:
>>> On Jun 20 2016, Junio C Hamano <gits...@pobox.com> wrote:
>>>> Nikolaus Rath <nikol...@rath.org> writes:
>>>>
>>>>> What's the best way to find all commits in a branch A that have not been
>>>>> cherry-picked from (or to) another branch B?
>>>>>
>>>>> I think I could format-patch all commits in every branch into separate
>>>>> files, hash the Author and Date of each files, and then compare the two
>>>>> lists. But I'm hoping there's a way to instead have git do the
>>>>> heavy-lifting?
>>>>
>>>> "git cherry" perhaps?
>>>
>>> That seems to work only the "wrong way around". I have a tag
>>> fuse_3_0_start, which is the common ancestor to "master" and
>>> "fuse_2_9_bugfix". I'd like to find all the commits from fuse_3_0_start
>>> to master that have not been cherry-picked into fuse_2_9_bugfix.
>
> Hmm, so the topology roughly would look like:
>
>             A'--B'--D' 2fix
>            /
>           o---A---B---C---D---E---F master
>       3start
>
> And you want to find commits in 3start..master that do not have
> equivalent in 3start..2fix
>
> "git cherry --help" starts like this:
>
>     NAME
>            git-cherry - Find commits yet to be applied to upstream
>
>     SYNOPSIS
>            git cherry [-v] [<upstream> [<head> [<limit>]]]
>
>     DESCRIPTION
>            Determine whether there are commits in <head>..<upstream>
>            that are equivalent to those in the range <limit>..<head>.
>
> Applying that to our picture, we want to find commits yet to be
> applied to 2fix, and do so by comparing the commits between
> 3start..master and 3start..2fix.
>
> I find that the first sentence of the description is fuzzy
> ("Determine whether" would imply that you would get "Yes/No" but
> what we want is "here are the commits that do not have counterpart
> in 2fix"), but we already know <upstream> corresponds to 2fix
> (i.e. we are finding ones yet to be applied to there, which can be
> inferred from the NAME line), so <head> must be 'master' That means
> that <limit> corresponds to 3start, and we will be comparing commits
> in two ranges:
>
>     master..2fix (i e. <head>..<upstream>, which is the same thing as 
> 3start..2fix)
>     3start..master (i.e. <limit>..<head>)
>
> So perhaps "git cherry -v 2fix master 3start"?

This works, thanks! I don't quite understand why though. I started by
saying that I want to know which commits in master are have been cherry
picked after 3start was branched to 2fix, so <limit>..<head> must be
3start..2fix, which only leaves "master" as <upstream>.  What's wrong
with that thought?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to