Re: [PATCH v5 06/10] fast-export: add new --refspec option

Jeff King [off-list ref] writes:

I think that is much nicer for the simple cases, but how do we handle
more complex rev expressions? One can say:

  git fast-export master ^origin

or even:

  git fast-export origin..master

The "^origin" is not a refspec, and finding the refspec in the
dot-expression would involve parsing it into two components. I think you
can come up with a workable system by parsing the arguments as revision
specifiers and then applying some rules. E.g., a positive ref "foo" is a
refspec "foo:foo", but negative "^bar" does not impact refspecs at all,
and the same rules are applied for "bar..foo". There is a syntactic
conflict where "foo:bar" would be interpreted as a tree:path by the
revision code, though, whereas in this context it means a refspec.

So I think it is possible to go that route (and perhaps preferable,
even, because it keeps the simple and common cases easy for the user),
but the implementation is not as simple as just treating the arguments
as refspecs.

I forgot about the ranges, but thinking about it further, I think
what we really need to worry about is the positive end.

	git fast-export origin..master

is (by the usual definition of A..B range) the same as

	git fast-export ^origin master

If we realize that the bottom ends of ranges do not participate in
the "update the ref at the receiving end" phase of object/history
transfer at all, that command line can still be thought of as a
short-hand for

	git fast-export ^origin refs/heads/master:refs/heads/master

That is, anything negative is used only to specify the bottom of the
range, and positive ones (e.g. 'master' in both of your examples) tell
us what ref to update in addition to where the history ends.