Junio C Hamano writes: > Try it on user inputs like "master..next", "next...master". You > wanted to grab only the positive ones, no? No... gitk passes the IDs it gets from git rev-parse (both positive and negative) to git log, rather than the original arguments. This is to avoid gitk having an incorrect idea about what commits git log has started from, in the situation where somebody changes some head or tag between when gitk does the git rev-parse and when it does the git log. That unfortunately means --left-right doesn't work however, because git log doesn't recognize "a b ^merge_base(a,b)" as being equivalent to "a...b". > And in order to handle them sanely without worrying about > revision machinery and rev-parse going out-of-sync, I would > almost suggest doing something like the attached patch and say: > > $ git rev-list --no-walk "$@" > > The user options can contain --left-right and --boundary, so the > output from this could begin with ">", "<" and "-". If you > discard the ones that are prefixed with "-" (i.e. the user had > the --boundary option in "$@"), grab the ones that are not > prefixed (i.e. the user did not have the --left-right option in > "$@"), and the ones prefixed with ">" and "<" (i.e. the user did > have --left-right, and you would strip the prefix from such a > line), you would find all positive ones the user specified, I > think. Yes, that would be useful. Now, if I can just think of a way to avoid the race, or work around it, the problem will be solved. :) I can probably do that by checking whether I see all the (positive) commits from git rev-list --no-walk in the git log output. Thanks, Paul. -- 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
