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 . 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):
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".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html