Re: git push (mis ?)behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux