Jonathan Nieder venit, vidit, dixit 02.07.2010 10:18: > 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? 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. > >> 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 -- 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