Subject: Re: [RFC PATCH] push: start warning upcoming default change for push.default

From: Holger Hellmuth <[email-masked]>
Date: Wed, 14 Mar 2012 20:15:23 +0100

On 13.03.2012 18:41, Junio C Hamano wrote:
> Holger Hellmuth<[email-masked]>  writes:
>> If Peff's "push to same branch in a different remote" is a bug (and
>> IMHO it is) it should not count as a reason for what should be the
>> default.
>
> I may phrased it poorly, but I don't think you mean "if the bug is fixed,
> then the behaviour of upstream is simple and easy to understand".  The

I think the behaviour of the whole pull/push system is not easy to 
understand. One has to learn a lot of concepts about git before being 
able to answer the simple question "if I do 'git push' now, what happens?".

Since I am using git without any collaboration I never had much need to 
play around with the whole porcelain remote configuration (cloning and 
using git config was enough). So today I tried to create a bidirectional 
link between a local and a remote branch using only porcelain commands 
(i.e. without using git config directly). Somehow I didn't succeed. I 
can either use git checkout --track or git push -u to make a pull 
connection between the two, but to automatically push I would have to 
create a branch of the same name (and know that this is the magical 
ingredient that makes it work!)

Maybe what is missing is a parameter to git-push that tells git that 
from now on this is what git push should do per default in this branch 
(Similar to what git checkout --track does). This would mean that even 
new users could do most remote configuration with just the knowledge of 
git checkout and git push.

By the way I think I found another "hole" in the porcelain: If you add a 
single branch to follow with git remote add -t <branch> ..., you can't 
add another. A second git remote add -t <otherbranch> ... will be met 
with an error that the remote is already configured. I would have to 
delete the remote and add it again with git add -t <branch> -t 
<otherbranch> ..... Or use a different remote name (which would be 
confusing later on). Did I miss something?