Re: tracking branch for a rebase

From: Jeff King <peff@peff.net>
Date: Sep 7, 2009, 08:43 UTC
Message-ID: <20090907084324.GB17997@coredump.intra.peff.net>
In-Reply-To: <7vfxaz9wfi.fsf@alter.siamese.dyndns.org>

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.

Show 12 quoted lines

> 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