[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

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

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to