If I have a local branch X, is it conceivable that if I ever want to push
it out to elsewhere on a regular basis, I would likely to push it to the
same branch at the same remote?
Yes. The exception could be if you push to multiple remotes---but in
that case, you have to issue multiple push commands anyway. X -> (R,Y)
is not a function, but (X,R) -> Y is.
Are these all? What I am trying to get at is if we can tweak the rules
without introducing too much configuration variables to cover all these
cases.
Traditionally, we said:
$ git push $there $ref
is _always_ a shorthand for
$ git push $there $ref:$ref
>
If we somehow tweak
this "$ref is a shorthand for $ref:$ref" rule to account for the tracking
branch.*.merge gives us, perhaps we can make the push easier to use.
This is nice indeed. My questions are:
1) can we assume backwards compatibility is not a problem? Or, in other
words, would this be 1.6.5 or 1.7.0 material? In the past, the list has
usually been very cautious about that, but if there's good reasons I
guess the answer can be "yes".
(4) "git push" is a synonym for "git push R" where R is the value of
branch.X.remote, or "origin" if there is no such configuration. This
will in turn trigger rule (1) above.
We could optionally make it a synonym for "git push X" (where X is
the name of the current branch), which would invoke rule (3) above,
which in turn would invoke rule (2) above. Perhaps "push only the
current branch" option in the configuration, or "git push HEAD" from
the command line, would trigger this alternate behaviour.
[i.e., looking up branch.*.remote for the current branch].
2) if I understand correctly, then "git push HEAD" would behave like
push.default=tracking rather than push.default=current. If so, how do
you provide push.default=current behavior? (Or maybe you don't care).
Would this apply to remote.*.push = HEAD too? (I think so). Are the
backward compatibility issues stronger in this case? (I also think so).
3) if the previous item turns out to be a problem, should we invent a
new kind of refspec? "HEAD:" is free to use, is it a good idea? (I
don't like it).
4) From an implementation point of view, how well will it fit the
existing code, or rather will it have to be special-cased all over the
place? I already didn't like the single special case I have in the "git
push --current" patch, though I think it's unavoidable.
I think one of the workflows quoted as the original motivation of Finn
Arne's series that added push.default also falls naturally out of this.
That's true, and I actually liked the idea very much. The fact that it
raises many questions is not necessarily a point down---adding new
configuration keys is definitely simpler to flesh out, but it may be
that it only reaches a local maximum of simplicity/expressiveness. In
my case the combination refspec/autosetuppush/pushHeadOnly is very
expressive, but it requires to be wrapped by porcelain "git remote
add"/"git clone" for the average user.
In the past I've seen the development of git follow the line of adding
more knobs to allow the experts to tweak them, but that could also be a
byproduct of the audience that this ML reaches.
In this case, I think the choice depends on how much effort can be
invested in answering the above questions.
Paolo
--
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