Re: Suggestion: make --left-right work with --merge

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.