Re: git push (mis ?)behavior

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 4, 2007, 16:24 UTC
Message-ID: <04A74C2E-272B-4F5C-9254-11C9244091AF@zib.de>
In-Reply-To: <204B0DD6-54B0-4436-AFC6-ABDA4510E5D5@wincent.com>

On Oct 4, 2007, at 5:54 PM, Wincent Colaiuta wrote:

Show 21 quoted lines

>> I do not find it very intuitive to mangle the push behaviour into the
>> naming of the local branch. I think it would be a good idea if the
>> two commands above would either both setup a pull/push relation
>> or both would setup a pull-only relation. If pull-only would be the
>> default another switch could be provided to establish a pull/push
>> relation, like
>>
>>    git checkout --track --push -b mynext origin/next
>>
>> Comments?
>
> Interesting. To me that doesn't seem to be intuitive at all. I  
> actually think it makes a lot of sense for the relationship to be  
> "one way" in the absence of matching ref names.
>
> Basically, the distributed model works because you know that if you  
> have the same commit hash in two repositories you're talking about  
> the same thing. Same thing goes for branches; if you expect to be  
> able to push back upstream then it's natural to expect that that  
> should only work if you have the same ref name to identify the  
> "what" that you're actually pushing to.

But how do multiple remotes fit into your model? Maybe my example above was a bit to simple. How about this one:

    git checkout --track --push -b masterA remoteA/master
    git checkout --track --push -b masterB remoteB/master

I understand what it means because I devised my local naming model. The model could look totally wrong to you, but it's in my repository. You'd never see it. But if it fits my mental model, why should git enforce its master-means-always-master-and-must-not-be-named-differently model?

	Steffen