On Tuesday 05 October 2010 16:29:50 you wrote:
A newbie colleague asked why: "git push <branch>" didn't work.
Although I know that "git push <repo> <branch>" is the correct
syntax, I think that he has a point. If branch.<branch>.remote
is defined it seems unambiguous to me.
So I can't see any reason NOT to dwimify
git push <branch>
Isn't that syntax reserved for remotes?
for example:
git push origin
I feel like it would be a bad idea to have these 2 types of invocations
overlap in syntax like that.
On Tue, Oct 5, 2010 at 3:11 PM, Daniel Johnson [off-list ref] wrote:
Isn't that syntax reserved for remotes?
for example:
git push origin
I feel like it would be a bad idea to have these 2 types of invocations
overlap in syntax like that.
The idea is that given "git push <branch>" if <branch> is NOT a remote but
IS a branch name then git could unambiguously provide the correct remote.
Naturally if there's a branch and a remote of the same name then for backwards
compatibility the remote would be chosen.
Hi,
On Tue, Oct 05, 2010 at 03:28:56PM -0700, Eric Raible wrote:
On Tue, Oct 5, 2010 at 3:11 PM, Daniel Johnson [off-list ref] wrote:
quoted
Isn't that syntax reserved for remotes?
for example:
git push origin
I feel like it would be a bad idea to have these 2 types of invocations
overlap in syntax like that.
The idea is that given "git push <branch>" if <branch> is NOT a remote but
IS a branch name then git could unambiguously provide the correct remote.
Naturally if there's a branch and a remote of the same name then for backwards
compatibility the remote would be chosen.
Please don't do that. Imho, this introduces too much magic in the
behavior of git-pull, making it less intuitive to understand and, thus
error-prone.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin