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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2013, 22:31 UTC
Message-ID: <xmqqr4at6u24.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20131106221427.GB13258@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 22 quoted lines

> 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.