[joining the discussion late; was travelling]
Duy Nguyen wrote:
> git co long-branch-name
> git diff A/@
> git reset --hard A/@
In this form, this looks highly inconsistent. You have to decide if
you want @ to resolve to the current branch name or HEAD. Our current
@-proposal makes @@{1} display the reflog for HEAD for instance. The
other problem is that we resolve things like @{-1} to full refs like
refs/heads/master. Making a A/@{-1} work makes little or no sense,
because that refs/heads needs to be changed to refs/remotes in the
first place. What about refs/decapitated/@{-1}? Should we support
it?
I tend to agree with Junio here: @{u} is the way forward. We need to
define useful reduced consistent semantics; while inventing a
mini-language to do all kinds of revision manipulations may be a fun
theoretical exercise, it's too much effort for too little gain. We
have to learn to work within the limitations of what we've invented so
far.
On Matthieu's note, I have a comment: symbolic refs are an absolute
dead end. We didn't think of it from the start, and it's too late
now. Do NOT go there: from my investigation, I believe that hooking
up everything to the revision parser is the way forward.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html