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

Jonathan Nieder venit, vidit, dixit 02.07.2010 10:18:

Michael J Gruber wrote:

quoted

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

quoted

quoted

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. ;-)

quoted

git cherry would be more useful if you could specify a "limit" which is
an ancestor of "fork-point", not only descendants.

quoted

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?

I suggest that I was reading limit on the wrong branch :|
What I meant was specifiying a different lower limit in 2 would help:
then you could force git cherry to compare more commits, if you have a
rough idea about how far to go back. But even being able to say
"v1.6.0..upstream" here instead of head helps and is much more efficient
then going for --full.

quoted

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

I guess it always pays to read the full thread before jumping in... your
"prefork" there is what I meant above.

Michael