Re: tracking branch for a rebase

Johannes Schindelin [off-list ref] writes:

How about ^^branch? *ducks*

You'd better duck.

Just like %branch, it is a selfish and short-sighted "good enough for this
particular case but there is no room for extending it" hack that I have
serious problem with.  It closes the door for people who come later, and
such an attitude is okay only if this is _the last great invention_ and
there is no more great feature that deserves short-and-sweet notation to
come.  It might be the _latest_ great invention, but chances are that it
won't be the last.

Seriously again, I think that ^{tracking} (with shorthand ^t, maybe) is 
not too shabby an option.  The point is: if we make this unattractive 
enough by requiring a lot of typing, we will never get to the point where 
it is popular enough to make a shorthand: it just will not be used at all.

I actually think it is the other way around.

If it is so useful to be able to specify the ref your branch is based on
by applying a magic to the name of your branch, the users will use it even
if it is rather long to type, as long as the feature is easy to discover
and remember, and then they will demand a short-hand.

If on the other hand users say "Hey, I know can say 'git log X@{upstream}'
but why bother?  I always build my branch X on top of origin/X anyway, so
I'd forego that feature and type 'git log origin/X'.  It's not worth my
time to type that long magic," then the feature is not as useful as you
hoped.  And there is no point in coming up with a short-hand syntax for
it.

I personally suspect that users love to use the feature _despite_ the
initial lack of short-hand, and we would end up adding some short-hand,
and that would be a far better proof that the feature itself is useful
than "it is used just %X happens to be shorter than origin/X".

But before that happens, I'd rather not waste short-hand notations, such
as @{t} or @{u}, that will be in short-supply in the longer term.