Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think I already said where I think we differ in a separate
message, but a
Santi Béjar sa...@agolina.net writes:
The next question could be: why not make it work with $url too? As in:
$ git merge git://git.kernel.org/pub/scm/git/git.git//master
You need to remember merge is a local operation, working in your
local repository. Like it or not, the UI of Git makes
Junio C Hamano gits...@pobox.com writes:
Just a few typofixes...
Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think I
El 06/05/2013 19:11, Junio C Hamano gits...@pobox.com va escriure:
Santi Béjar sa...@agolina.net writes:
The next question could be: why not make it work with $url too? As in:
$ git merge git://git.kernel.org/pub/scm/git/git.git//master
You need to remember merge is a local operation,
On Mon, May 6, 2013 at 7:06 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think
Johan Herland jo...@herland.net writes:
Ok, so whereas I consider the refspec to be king, and that the expansion
from convenient shorthands to full remote-tracking refnames should be
derived from the chosen refspec, you would (if I understand you correctly)
rather have a constant (i.e.
On Sun, May 5, 2013 at 6:28 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
The $remote/$branch syntax can be interpreted in two subtly different
ways:
1. A shorthand name for the remote-tracking branch corresponding to a
specific $branch from a
Johan Herland jo...@herland.net writes:
I want to extend the same reasoning to remote-tracking refs, i.e.
$remote/$name could be auto-completed into any of
refs/remotes/$remote/$name
refs/remotes/$remote/tags/$name
refs/remotes/$remote/heads/$name
without causing ambiguity in the
On Sun, May 5, 2013 at 9:02 PM, Junio C Hamano gits...@pobox.com wrote:
So another issue that remains is the following, I think.
When interpreting $nick/$name, assuming that we can tell where $nick
for a remote ends and $name for the ref we take from the remote
begins [*1*], how would we
Johan Herland jo...@herland.net writes:
This would not allow the user to use the relevant $remote_name for $nick,
which I argue might be the more natural name for the user to use, since
it's the same name that is used for otherwise interacting with the remote.
That is where we differ.
The
El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió:
Johan Herland jo...@herland.net writes:
This would not allow the user to use the relevant $remote_name for $nick,
which I argue might be the more natural name for the user to use, since
it's the same name that is used for
2013/5/6 Santi Béjar sa...@agolina.net:
El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió:
Johan Herland jo...@herland.net writes:
This would not allow the user to use the relevant $remote_name for $nick,
which I argue might be the more natural name for the user to use, since
Johan Herland jo...@herland.net writes:
The $remote/$branch syntax can be interpreted in two subtly different
ways:
1. A shorthand name for the remote-tracking branch corresponding to a
specific $branch from a specific $remote.
2. A refname fragment, which - when appended to
13 matches
Mail list logo
