Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> Junio C Hamano wrote: >>> IOW, make these: >>> >>> $ git push HEAD >>> $ git push next >>> >>> push the obvious thing to the default remote, I _think_ we can >>> achieve the same effect as --current and a bit more. >> >> The only problem would be when there is conflict between remote name and >> branch name... What about idea of using "--" to separate remote from branchname? > Yes. *If* we were to do that fallback it has to be something > like this: > > (1) does $0 look like remote and $1..$n look like a refspec? If > so do not fallback; By "look like remote" you mean that there is [remote "$0"] section in config (I guess that we can not support old .git/remotes/<remote> configuration for _new_ features, especially that there exist script converting to new way of configuring remotes, contrib/remotes2config.sh) > (2) Do we have branch.$current.remote? If not, we cannot > fallback so error out. Do not fallback to "origin"? > (3) otherwise, does $0 look like a refspec? If so, try insert > it before the params, treating $0..$n all refspecs. You mean $0 is existing branch, or of the form branch:<whatever>? Or should we forbid remote names containing ':'? >> BTW. what would happen for "git push branch1 branch2" if branch1 has >> different remote than branch2? > > Read my example more carefully. It says "push HEAD" and "push > next" while on 'pu' and it takes branch.pu.remote. Somehow I missed that $current means _current branch_ (branch we are on, which defines default remote). -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
