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