El 4/10/2007, a las 16:47, Steffen Prohaska escribió:

quoted text
> On Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:
>
>> On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:
>>
>>> I wonder how hard it would be to teach _everybody_ to specify
>>> _exactly_ what they want.
>>>
>>> Of course, we'd need an "--existing" option to git-push to trigger
>>> the behaviour that we have right now.
>>
>> I could _definitely_ live with that. If the branch config doesn't say
>> what to do when no arguments are given, then demand a  
>> specification on
>> the command line.
>>
>> I'll shut up on this topic now, though, since I'm not exactly helping
>> with the patch/opinion ratio.
>
> Here is an interesting related pitfall where my expectations about
> the behaviour of git push in relation with tracking branches were
> wrong. I should have know better, but I somehow forgot the details.
> I expected that the following would establish a two-way link, not
> only a one way link:
>
>    git checkout --track -b mynext origin/next
>
> sets up a tracking branch and "git pull" fetches and merges changes
> from origin/next as expected.
>
> I somehow expected that "git push" would push changes from mynext to
> origin/next. But it doesn't. It would only do so if I had chosen
> the same name for the local branch, that is
>
>    git checkout --track -b next origin/next
>
> would have set up a two-way link -- but maybe only as long as I don't
> have other push lines in my config file. I'm not sure about the last
> point.
>
> 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.

Cheers,
Wincent

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html