Re: [PATCH v3 0/3] add push --current and remote.*.pushHeadOnly

[Paolo Bonzini <bonzini@gnu.org>]

> 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