Re: [PATCH] Documentation: 'cherry' does not cope well with merges from upstream

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 2, 2010, 08:18 UTC
Message-ID: <20100702081812.GA9219@burratino>
In-Reply-To: <4C2D995D.2020708@drmicha.warpmail.net>

Michael J Gruber wrote:

> Jonathan Nieder venit, vidit, dixit 01.07.2010 23:09:

Show 5 quoted lines

>> Add a BUGS section to explain the problem.
>
> This is not a bug. git cherry works exactly as described.
> 
> At worst, it is a misfeature.

Unix man pages have a history of using BUGS sections to describe misfeatures and even unavoidable design constraints.

One nice effect is to encourage people to think of programs as fixable. But maybe it is bad PR. ;-)

Show 6 quoted lines

> git cherry would be more useful if you could specify a "limit" which is
> an ancestor of "fork-point", not only descendants.
>
>> Thoughts?  Improvements?
>
> Allow general "limit" :)

Hmm, I am not totally sure I understand. Conceptually ‘git cherry’ currently does something like the following:

 1. List all commits limit..head and find their patch ids
    (limit defaults to upstream if not specified)

 2. List all commits head..upstream and find their patch ids

 3. For each commit listed in step 1, check if it is in the
    list from step 2 and print its commit id with a + or -
    accordingly.

Are you suggesting that the limit should replace head in step 2? Or something else?

> git-cherry(1) never speaks about upstream..head nor head..upstream. It
> uses "fork-point", and a merge creates a new "fork-point", i.e.
> merge-base.

This explanation becomes problematic when there is more than one merge-base: http://thread.gmane.org/gmane.comp.version-control.git/150067/focus=150093

Thank you for the comments. I considered using the <limit> argument to work around this but didn’t try the modification you suggest above. I would be happy to find that it works (generalized for repos with a more shallow history to --full).

Sleepily, Jonathan