Having to read this three times made me irritated enough to comment on
this part of the cover letter.
Sorry (you weren't CCed on v1, though, were you?).
For me, the inherent problem of push.default is that it is a global
setting. As you say below, different remotes may have different
characteristics and this can happen within the same repository.
One example is an integrator (push.default=matching) that also develops
a few topic branches and wants to publish his tree so that people can
peek at them --- at the same time, he wants to be free to rebase there.
He can then use --mirror to set up the latter remote.
Now, instead, we have a person working in a set up like the one Finn
described. He is a subsystem integrator, so he publishes some stable
branches (push.default=matching again). For development, however, he
has to branch off the repositories published by other subsystem
integrators; for these he wants push.default=tracking semantics. He
then has to define push.default=tracking and configure the other remote
manually. Unlike the first user, this one needs to make a global
decision and adjust the git configuration whenever this global decision
does not fit.
In addition, if he wants to disable pushing to some repository, he
cannot use push.default=nothing anymore. The problem is that "the
exception [the setting of push.default that was desired for one
repository] became the rule [the global per-repository push.default
setting]", and this happened because there is no way to realize
push.default=tracking with the usual set of git tools, namely refspecs
and checkout -t.
While trying to understand the problem, I tried to see what it would
take to implement push.default using the existing git tools, and what
extra features would be needed. The resulting design had three new
features (per-remote tracking, autosetuppush and pushHeadOnly), and
everything else built on top of those (the --push patch series I posted
today). I actually liked the design, and decided it was worth pursuing
it instead of just turning push.default into a per-remote configuration.
It is way bigger than the push.default patches; on the other hand the
three new features may be otherwise desirable, and it also includes some
nice cleanups. However, because of this I placed too much attention to
the separate features and failed to show the big picture and what was
missing in the 1.6.3 implementation.
(Now, back to your comments).
[...] If on the other hand your workflow is to fork topics from the remote
integration branch(es) (e.g. topicA and fixB both forked from master taken
from the remote), both topics will be set to push back to the same master
branch on the remote side if you use branch.autosetuppush. In such a
workflow, you work on these two topics, and when one of them is done, you
want to push that one out, without having to push the other one that is
not yet ready (beside, that one won't fast-forward).
A "tracking" push that pushes all branches is actively a wrong thing to do
in such a workflow.
Agreed.
autosetuppush is in fact not meant to be used by the usre, at least the
casual user who restricts himself to the "git remote" porcelain and
prefers not to deal into .git/config whenever possible. The idea is
that the user can use --push=tracking to express his workflow, and this
will set up pushHeadOnly and autosetuppush together. The combination of
the two options is safe, and provides the behavior that best suites the
user's workflow.
(Writing this final paragraph is what made me realize me that I was
wrong in not showing the big picture in the beginning. Giving hints
through the cover letters was not enough).
> In short, it is not necessarily bad that "push all matching" is much
> easier to set up and use than "push all tracking", and I think it is
> nothing to be annoyed about.
The problem is, when "the exception becomes the rule", is it still true
that "push all matching" is easier to set up?
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