Re: git push (mis ?)behavior

[Wincent Colaiuta <win@wincent.com>]

El 4/10/2007, a las 18:24, Steffen Prohaska escribió:

> On Oct 4, 2007, at 5:54 PM, Wincent Colaiuta wrote:
>
>>> 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?

I think I'll leave it up to someone who knows a bit more than me to  
answer that one... It's not a use case I've ever sought out as I  
usually only work with one upstream remote. Sorry I don't have  
anything intelligent to add.

Cheers,
Wincent