On Mon, Jul 14, 2014 at 06:51:22AM -0300, David Bremner wrote:
> W. Trevor King writes:
> > On Sun, Jul 13, 2014 at 09:30:56AM -0300, David Bremner wrote:
> >> I consider it a useful feature that it works without the user
> >> configuring a local branch.  I agree that in more complex setups
> >> this ambiguity is not as nice, but I'd rather it was only the
> >> minority of users with unusual setups (e.g. multiple remotes)
> >> have to do configuration.
> >
> > I could work up a patch that tried ‘git show-ref -s config’ first,
> > and only fell back to ‘show-ref -s --heads’ if there were multiple
> > matches.  That way folks with only origin/config wouldn't need a
> > local branch, but folks with multiple config-carrying remotes (or
> > a single config-carrying remote and a local branch) would have to
> > have a local config to break the tie.  That's possible, and not
> > *too* complicated, but I personally prefer the consistency of just
> > requiring a local config branch.
>
> It might be simpler to implement (and understand) to try first the
> local config branch and then fall back to "origin/config".

I'd rather avoid hard-coding an upstream name here.  We do hard-code
‘origin’ as the default remote for ‘fetch’, ‘pull’, and ‘push’.  I'd
rather drop those in favor of the configured Git defaults (for
example, running a bare ‘git fetch’ if the user doesn't specify a
remote).  For most configurations, falling back to “Is ‘git show-ref
-s config’ a unique hash?” should be equivalent to hard-coding ‘git
show-ref -s origin/config’.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy