Duy Nguyen pclo...@gmail.com writes:
On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.
Actually, ref-alises are
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
However, there is an alternative solution to the issue: overload the
character @ to
On Tue, Apr 30, 2013 at 7:24 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
Ramkumar Ramachandra artag...@gmail.com writes:
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
However, there is an alternative
Thomas Rast wrote:
But then why don't you just 'git symbolic-ref H HEAD' for a sort of
local alias?
Yes, I already have @ pointing to HEAD. And I think it's much nicer
than H (also since H@{u} doesn't resolve [1]). The purpose of this
patch is to standardize @ for everyone.
What annoys me
On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:
This patch has the exact same effect as:
$ git symbolic-ref @ HEAD
But then why don't you just 'git symbolic-ref H HEAD' for a sort of
local alias?
For me, it's because I don't want to do that on every repo. One day if
I
On 04/30/2013 05:04 PM, Duy Nguyen wrote:
On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:
What annoys me more is that there's no way to say
git symbolic-ref U @{u}
so that I can avoid that -- it's really clumsy to type on a Swiss German
keyboard. We'd need some sort of
Duy Nguyen pclo...@gmail.com writes:
It's not hard to do. The below patch makes . equivalent to HEAD and
.U - @{u}. Refs are not supposed to have '.' at the beginning, so
it's easy ...
How is the equivalent of master..@{u} expressed? master...U? How is
it disambiguated from a symmetric
On Tue, Apr 30, 2013 at 11:09 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
It's not hard to do. The below patch makes . equivalent to HEAD and
.U - @{u}. Refs are not supposed to have '.' at the beginning, so
it's easy ...
How is the equivalent of
Junio C Hamano wrote:
We need to see if we can make the explanation we will give
to end users is understandable.
I'll make an attempt.
@ can be used in two contexts:
1. When used without the {}, it means HEAD.
2. When used with a {}, it means what those three forms individually
mean. @{}
Duy Nguyen wrote:
We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.
Actually, ref-alises are the right way to solve the problem.
Recursive symref peeling is a bad idea: I can't take my aliases with
me, and they
Junio C Hamano wrote:
git update-ref HEAD $commit is accepted. If @ is a synonym for
HEAD, git update-ref @ $commit should work exactly the same way,
but is it desirable?
Would we have $GIT_DIR/@ as the result? How
about git symbolic-ref?
Yes, it is a valid refname that can be overridden
On Tue, Apr 30, 2013 at 12:23 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
Would @@{4} and HEAD@{4} be the same?
No. Why should they?
Why would HEAD^0^0~4 work? Because the syntax is recursive.
--
Felipe Contreras
--
To unsubscribe from this list: send the line
Felipe Contreras wrote:
Why would HEAD^0^0~4 work? Because the syntax is recursive.
That's because you can compose with ^ and ^, while you can't with @
and @. Does @{0}@{0} resolve?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Ramkumar Ramachandra artag...@gmail.com writes:
Felipe Contreras wrote:
Why would HEAD^0^0~4 work? Because the syntax is recursive.
That's because you can compose with ^ and ^, while you can't with @
and @. Does @{0}@{0} resolve?
@{-1}@{0} does. That means @{0} is a revision and not a
Junio C Hamano wrote:
@{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}
is.
Right. I missed that.
'@ given alone' has to be a ref if we want @@{5.minutes.ago} to
resolve.
Yeah, I just realized that it's a bug in the @{u} implementation.
@@{5.minutes.ago} and @@{1}
Ramkumar Ramachandra wrote:
@@{5.minutes.ago} and @@{1} work perfectly fine on git.git master.
(with the .git/@ symref obviously)
--
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
Ramkumar Ramachandra wrote:
Therefore, @@{5.minutes.ago} should work with my implementation too.
Caveat: we won't keep reflogs for @ unless the manual override .git/@
is present (what's the point of keeping a duplicate of .git/logs/HEAD
in .git/logs/@?). So, without the .git/@, @@{1} will
Ramkumar Ramachandra wrote:
So, without the .git/@, @@{1} will complain that
the reflog only has 1 entry (in other words, it is correct but not
useful).
Even better idea. When not overridden, @@{n} will show the reflog
for HEAD. To the user, it looks like @ is behaving like a true ref by
On Tue, Apr 30, 2013 at 1:22 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
@{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}
is.
Right. I missed that.
'@ given alone' has to be a ref if we want @@{5.minutes.ago} to
resolve.
Yeah, I just
On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
We could put still ref aliases
into the same ref namespace, with lower precedence that actual refs,
so no new syntax required.
Actually, ref-alises are the right way to solve the problem.
21 matches
Mail list logo
