Junio C Hamano <gitster@xxxxxxxxx> writes:
> I do not think you would need a new option for this, by the way.
> Just add a new syntax for the LFS of a refspec that cannot possibly
> be confused with existing choices of what can come there (i.e. an
> empty string to denote deletion, or a partial refname), e.g. come up
> with an appropriate string in $sign and allow the following:
>
> $ git fetch ${sign}c78f7b5ed9dc
> $ git fetch ${sign}c78f7b5ed9dc:refs/remotes/origin/frotz
>
> to do the obvious thing, perhaps? We could even allow some form of
> extended SHA-1 expressions with some restrictions ...
Note that the above example already uses a form of extended SHA-1
expression, and I personally do not think we should support it in
the very initial version.
This is because the actual object name, if resolved on the remote
side, will not be known by "fetch". To support the "resolve on the
remote end", we would need protocol extension to have the remote end
tell the "fetch", i.e. "you asked to fetch HEAD@{4}, the exact
object name for that is 030000f4c81729d2cb862a317e41a60a7111b98d";
otherwise we cannot add a line to FETCH_HEAD and cannot update the
RHS of the refspec.
Instead, we should limit us to 40-hex object name and nothing else
in the initial incarnation.
i.e.
$ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
$ git fetch ${sign}c78f7b5ed9dc1c6edc8db06ac65860151d54fd07:refs/remotes/origin/frotz
If the remote end (which, as Peff pointed out earlier, already knows
how to respond to a fetch request for an exact object when
configured to do so) allows such a fetch to go through, "fetch" can
(and will) update the ref named by the RHS of storing refspec with
the current code, so there is no need to do anything special to
support this.
As to ${sign}, I was tempted to say an empty string might be
sufficient (i.e. "do not use 40-hex as your branch name"), but it
probably is a bad idea. A single dot "." would be a possibility
(i.e. a ref component cannot begin with a dot), but squating on it
and saying "anything that begins with . must be followed by 40-hex
(and in the future by an extended SHA-1)" would rob extensibility
from us, so perhaps ".@c78f7b5ed9dc1c6edc8db06ac65860151d54fd07" or
something? That is leading "." denotes "this is an extended refspec"
and the next character denotes what kind of extended refspec it is.
For now we say that "@" denotes "exact object name is used instead
of a(n abbreviated) refname".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html