Johan Herland [off-list ref] 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 thing is, when you name a local ref (be it "refs/heads/master"
or "refs/remotes/origin/master") with a short-hand, you are still
dealing with a refname, not interacting with the remote at all.
Taking notice of remote.$nick.fetch mappings only to complicate the
refname resolution logic is absolutely unacceptable, at least to
somebody who comes from the "we are interacting with refs, not with
remotes" school, like me.
El 06/05/2013 00:36, "Junio C Hamano" [off-list ref] escribió:
Johan Herland [off-list ref] writes:
quoted
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 thing is, when you name a local ref (be it "refs/heads/master"
or "refs/remotes/origin/master") with a short-hand, you are still
dealing with a refname, not interacting with the remote at all.
Taking notice of remote.$nick.fetch mappings only to complicate the
refname resolution logic is absolutely unacceptable, at least to
somebody who comes from the "we are interacting with refs, not with
remotes" school, like me.
Maybe we could mark it explicity with a double slash: "$remote//$branch",
or similar. And it even allows a slash in the remote nick: "bar/baz//foo".
See you,
Santi
P.D: Resend because the list rejected it, sorry for the duplicate.
2013/5/6 Santi Béjar [off-list ref]:
El 06/05/2013 00:36, "Junio C Hamano" [off-list ref] escribió:
quoted
Johan Herland [off-list ref] writes:
quoted
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 thing is, when you name a local ref (be it "refs/heads/master"
or "refs/remotes/origin/master") with a short-hand, you are still
dealing with a refname, not interacting with the remote at all.
Taking notice of remote.$nick.fetch mappings only to complicate the
refname resolution logic is absolutely unacceptable, at least to
somebody who comes from the "we are interacting with refs, not with
remotes" school, like me.
Maybe we could mark it explicity with a double slash: "$remote//$branch",
or similar. And it even allows a slash in the remote nick: "bar/baz//foo".
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
But I don't know if it can be problematic...
I remember that there was a discussion about the remote#branch
notation used in cogito, and at the end it was rejected.
See you,
Santi