Re: tracking branch for a rebase

Jeff King <peff@peff.net> writes:

That's a sane suggestion, I think. We can always have a descriptive longhand (e.g. "branch@{upstream}") and later add a shorthand for often used ones (e.g. "branch^up", "branch/.up" --- the former is possible because it cannot be upth parent of the commit at the tip of the branch, and the latter is possible because component of hierarchical refname cannot begin with a dot).

I find a prefix % not descriptive enough (besides being ugly); if it were "^branch", as some people said, it would probably have matched its meaning "up", but that notation is already taken for "uninteresting". If we are going to use funny symbol as a notation to invoke magic, I think it is easier for new people if we limit the number of symbols used. We already have ^n, ^{type} and ~n magic, all of which operate on objects and peel them in three different ways.

Then there currently is only one kind of magic that works on refs and it is spelled as ref@{magic}. Let's try not to introduce more notation before it is absolutely necessary.

When I say there is only one kind of magic notation for refs, I am primarily talking about the end-user perception. @{time}, @{number} and @{-number} all do their magic using the reflog, but that is about _how_ they do what they do. End-user perception begins with _what_ they do, and at that level, the magic consistently works on refs and different genie is summoned depending on what is inside {}.

The @{upstream} thing won't be using reflog to do its job, but that is about _how_ it is implemented, and the end users don't care.

What is more important is _what_ it does. Given a ref, the @{} magic notation finds something that is related to the ref. @{time} and @{number} finds what the ref itself used to point at. @{-number} (applicable only to HEAD ref) finds the ref it used to point at. And @{upstream} will find another ref that it merges from (or rebases onto).