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

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

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.