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