On Sun, Mar 17, 2013 at 06:00:08AM +0530, Ramkumar Ramachandra wrote:
> >> +remote.pushdefault::
> >> + The remote to push to by default. Overrides the
> >> + branch-specific configuration `branch.<name>.remote`.
> >
> > It feels unexpected to see "I may have said while on this branch I
> > push there and on that branch I push somewhere else, but no, with
> > this single configuration I'm invalidating all these previous
> > statements, and all pushes go to this new place".
> >
> > Shouldn't the default be the default that is to be overridden by
> > other configuration that is more specific? That is, "I would
> > normally push to this remote and unless I say otherwise that is all
> > I have to say, but for this particular branch, I push to somehwere
> > else".
>
> I'm a little confused as to where this configuration variable will be
> useful. On a fresh clone from Github, I get branch.master.remote
> configured to "origin". How will adding remote.pushdefault have any
> impact, unless I explicitly remove this branch-specific remote
> configuration? Besides, without branch.<name>.remote configured, I
> can't even pull and expect changes to be merged. So, really: what is
> the use of remote.pushdefault?
>
> I'm dropping this patch, and just going with branch.<name>.pushremote,
> unless you convince me otherwise.
That is why I described the scheme I did in [1]. It uses the following
two general rules:
1. Per-branch config trumps repo-wide config.
2. Push-specific config (e.g., "remote.pushdefault") trumps
non-specific config (e.g., "remote.default") for pushing.
So the push lookup list is (in order of precedence):
1. branch.*.pushremote
2. remote.pushdefault
3. branch.*.remote
4. remote.default
5. origin
and it solves Junio's issue because the way to say "override my
remote.pushdefault for this branch" is not to set "branch.*.remote", but
to set "branch.*.pushremote".
-Peff
[1] http://article.gmane.org/gmane.comp.version-control.git/215751
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
