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

[Jeff King <peff@peff.net>]

On Wed, Nov 06, 2013 at 01:00:42PM -0800, Junio C Hamano wrote:

> I didn't think things through, but at the external UI level, I see a
> possibility of a nicer way to express the above.
> 
> In our "push" refspec (and export is about pushing what we have), a
> colonless refspec A is a short-hand for A:A, so the traditional
> 
> 	git fast-export master
> 
> can be thought of, in a new world order with a patch that lets you
> do a ref mapping, a short-hand for an identical mapping:
> 
> 	git fast-export master:master
> 
> It follows that the syntax naturally support
> 
> 	git fast-export refs/heads/master:refs/heads/foobar
> 
> I would think.
> 
> That approach lets you express ref mapping without a new option
> --refspec, which goes contrary to existing UI for any commands in
> Git (I think nobody takes refspec as a value to a dashed-option in
> the transport; both in fetch and push, they are proper operands,
> i.e. command line arguments to the command), no?

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.

-Peff