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
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html