On Sun, Sep 06, 2009 at 10:05:21PM -0700, Junio C Hamano wrote:
> At-mark currently is reserved for anything that uses reflog, but we can
> say that it is to specify operations on refs (as opposed to caret and
> tilde are to specify operations on object names).
I assume you meant that @{} is reserved; my reading of the previous
discussion was that "foo@bar" is still valid.
> It specifies what ref to work on with the operand on its left side (and an
> empty string stands for "HEAD"), and what operation is done to it by what
> is in {} on the right side of it. This view is quite consistent with the
> following existing uses of the notation:
>
> ref@{number} -- nth reflog entry
> ref@{time} -- ref back then
> @{-number} -- nth branch switching
>
> So perhaps ref@{upstream}, or any string that is not a number and cannot
> be time, can trigger the magic operation on the ref with ref@{magic}
> syntax?
I think using @{} is a reasonable extension format. It's easy to read
and syntactically obvious. We need to watch out for conflicts with
things that might be valid times, but that is an easy thing to check
when adding new keywords. The only danger would be some extension
specifier that used arbitrary input, but that would probably be prefixed
with a keyword (and I can't even think of an example extension that
would want arbitrary input).
My only two complaints with ref@{upstream} are (and I don't think either
is a show-stopper, but maybe something we can improve on).
1. It is a nice abstraction, but it doesn't save typing in most cases.
"origin" is shorter than "master@{upstream}". One of the desired
features in the last thread was that it be very short (which isn't
to say we can't introduce @{upstream} _now_ and add a shorter
synonym later on).
2. I assume @{upstream} will be equivalent to HEAD@{upstream}. What
should it do? The most useful thing to me would be to find the
upstream for the current branch. But that is actually quite
different from how HEAD@{1} works, which looks at the reflog for
HEAD and not the branch.
Maybe this is an inconsistency we can live with. The features are,
after all, only syntactically related. I was just hoping to keep
things as simple as possible for users to understand (and they
often take semantic clues from syntax).
And some final thinking out loud in this area (i.e., these ideas are, I
think, somewhat half baked):
We already have some reserved uppercase ref names like HEAD, FETCH_HEAD,
ORIG_HEAD, and MERGE_HEAD. One option would be to declare all-caps
names as reserved and allow UPSTREAM for the feature in question. I can
think of two arguments against it:
1. The obvious one, that somebody somewhere is using all-caps and we
are breaking their setup.
2. It is not syntactically obvious to the user that it is not a real
ref, but rather a magic name. Users are accustomed to punctuation
introducing magic, so @{upstream} is probably better in that regard.
So I think that is a bad idea. But what about allowing "ref aliases"?
Obviously a static one like "f" for "foo" is kind of lame. But if you
could use the extension syntax, like:
git config refalias.% '@{upstream}'
then we can let people set up whatever shorthand they think is sane (and
without worrying about clobbering unlikely-but-allowed setups, since
they are in control of their setup).
Like I said, I am not sure that is not half-baked. ;)
-Peff
--
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