On Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:

quoted text
> 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?

	Steffen-
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