Junio C Hamano [off-list ref] writes:
Duy Nguyen [off-list ref] writes:
quoted
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
[off-list ref] wrote:
quoted
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
use 'git show @~1', and all that goody goodness.
I like this. I haven't spent a lot of time on thinking about
ambiguation. But I think we're safe there. '@' is not overloaded much
like ':', '^' or '~'.
quoted
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
'master@'.
I'm a bit reluctant to this. It looks like incomplete syntax to me as
'@' has always been followed by '{'. Can we have the lone '@' candy
but reject master@ and HEAD@? There's no actual gain in writing
master@ vs master@{0}.
Originally I was going to say the same, but after thinking about it
a bit more, I changed my mind.
Let me change my mind once again ;-)
As @ has been a valid character in a ref, I think "git show master@"
and "git show HEAD@" _should_ error out, not because they suffix
'master' and 'HEAD" in a funny way, but simply because there is no
branch called 'master@' (i.e. 'git for-each-ref | grep master@'
yields empty). After you run "git branch master@ master~26", you
should see "git show master@" not to error out, because that is just
the name of a branch with somewhat an unusual name.
And we can still have "git show @" to do "git show HEAD", based on a
world model completely different from I (incorrectly) advocated in
the message I am replying to.
The rule would be "You should be able to say '@' where-ever you
currently say HEAD" (aka '@' is a short-hand for 'HEAD').
That means "git checout @" should work the same way as "git checkout
HEAD", "git log @~4" would work the same way as "git log HEAD~4",
"git update-ref @ $(git rev-parse master)" should update the HEAD
without creating $GIT_DIR/@, etc.
You can't go any simpler than that rule, and there is no room for
confusion if that rule is properly implemented.
Hmm?
Junio C Hamano wrote:
[...]
You can't go any simpler than that rule, and there is no room for
confusion if that rule is properly implemented.
In other words: the sequence "@" is short for "HEAD". Isn't that
_exactly_ what I implemented in my two-liner?
However, I'm tilting towards respecting .git/@ as a manual override.
Why? Because we'd have to either claim that git symbolic-ref @ HEAD
is a noop, or deny it altogether (by saying that @ is not a valid
symbolic ref). The latter approach obviously sounds more sensible,
but I don't like unnecessarily eating up @.
On Tue, Apr 30, 2013 at 2:42 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Duy Nguyen [off-list ref] writes:
quoted
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
[off-list ref] wrote:
quoted
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
use 'git show @~1', and all that goody goodness.
I like this. I haven't spent a lot of time on thinking about
ambiguation. But I think we're safe there. '@' is not overloaded much
like ':', '^' or '~'.
quoted
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
'master@'.
I'm a bit reluctant to this. It looks like incomplete syntax to me as
'@' has always been followed by '{'. Can we have the lone '@' candy
but reject master@ and HEAD@? There's no actual gain in writing
master@ vs master@{0}.
Originally I was going to say the same, but after thinking about it
a bit more, I changed my mind.
Let me change my mind once again ;-)
As @ has been a valid character in a ref, I think "git show master@"
and "git show HEAD@" _should_ error out, not because they suffix
'master' and 'HEAD" in a funny way, but simply because there is no
branch called 'master@' (i.e. 'git for-each-ref | grep master@'
yields empty). After you run "git branch master@ master~26", you
should see "git show master@" not to error out, because that is just
the name of a branch with somewhat an unusual name.
There is also no branch named master@{0}. And there are no branches
with @{ in them, because we forbid them. So the question is what do we
want to forbid? If we don't want to forbid 'master@', then sure
'master@' should not evaluate to 'master'.
And we can still have "git show @" to do "git show HEAD", based on a
world model completely different from I (incorrectly) advocated in
the message I am replying to.
The rule would be "You should be able to say '@' where-ever you
currently say HEAD" (aka '@' is a short-hand for 'HEAD').
That means "git checout @" should work the same way as "git checkout
HEAD", "git log @~4" would work the same way as "git log HEAD~4",
"git update-ref @ $(git rev-parse master)" should update the HEAD
without creating $GIT_DIR/@, etc.
You can't go any simpler than that rule, and there is no room for
confusion if that rule is properly implemented.
I disagree. I can do 'git log @{-1}-4', but I cannot do 'git
update-ref @{-1}'. Why? Because the '@' notation is for revision
parsing, and 'git update-ref' doesn't do revision parsing.
I'd say, everywhere where you could do @{-1}, you should be able to do @.
Cheers.
--
Felipe Contreras