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

> Michael J Gruber wrote:
>> Jonathan Nieder venit, vidit, dixit 01.07.2010 23:09:
> 
>>> 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. ;-)
> 
>> 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