Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Questionable.  Did the user mean to say Z is positive when he said
>
> 	$ git rev-list A B ^C ... --not G H ... ^Z

Having said all that, I think you wanted a way to reconstruct various
different command lines that ends up in the same set of "pending objects",
and I do think that is something we need to address, as our command line
parsing heavily depend on the preprocessing phase of the revision
traversal machinery, and some commands do want to act differently between
the case when they are given "master" vs "master^0" for example (i.e. does
the user mean the branch as a whole or the commit at the tip?  If the
former the command may want to do something to the refs/heads/master while
the latter the command may work only on the commit or outright reject the
request saying "I only work on a branch").

In other words, I am not opposed to an effort to give the callers to the
"pending objects" machinery a better way to discover what the user told us
from the command line, giving them more than just "at the end of the
UNINTERESTING marking here are the objects listed on the command line and
you can look at their flags".  For example, some commands may want to tell
"a..b" and "^a b" apart, and other commands may want to tell what "a" was
when the user asked for exotic things like "a^@" or "a^!".

It may make sense to change the new "flag" field that can express only one
bit in your implementation to something more descriptive to express "what
command line option did this come from".  For example,

	git cmd a...b

that calls setup_revisions() may put "a" (positive), "b" (positive), and
zero or more commits that are their merge bases (negative) in pending
objects queue. Right now, these pending object entries may have some part
of the string being parsed as their name, but we may want to annotate all
the object array entries that result from "a...b" with the same "a...b"
(or a structure that represents its parsed form), so that the caller can
notice things like (1) they came from the single command line argument,
(2) the user didn't list random negative commits but they are meant as
merge bases between a and b, (3) a and b were written as such, not as
their abbreviated object names, etc.

Then "git fast-export master..master" can notice that there are two object
array entries in the pending object queue, they came from the same command
line argument, whose parse tree is a "unsymmetric difference between
string 'master' and string 'master'", and take the last piece to convince
itself that the user is talking about the master branch, even though as
the set arithmetic the result is an empty set, and do something
intelligent about the master branch.