Re: [PATCH] branch: make sure the upstream remote is configured

From: Jeff King <peff@peff.net>
Date: Jul 26, 2013, 23:12 UTC
Message-ID: <20130726231211.GB12968@sigill.intra.peff.net>
In-Reply-To: <1374877787.2670.6.camel@centaur.cmartin.tk>

On Sat, Jul 27, 2013 at 12:29:47AM +0200, Carlos Martín Nieto wrote:

Show 6 quoted lines

> > Is it nonsensical? It does not make sense for the @{upstream} magic
> > token, because we will not have a branch in tracking branch refs/remotes
> 
> This was the main point, yes; the only time I've seen it used is by
> mistake/misunderstanding, and thinking that you wouldn't want to do
> something like what's below.

If that is what you want to prevent, I do not think checking for a named remote is sufficient. You can also be pushing to a branch on a named remote that is not part of your fetch refspec, in which case you do not have a tracking branch. I.e.:

  git clone $URL repo.git
  cd repo.git
  git push --set-upstream HEAD:refs/foo/whatever

For that matter, I wonder what "--set-upstream" would do if used with "refs/tags/foo". You would not do that in general, but what about:

  git push --set-upstream master:master master:v1.0

I didn't test.

Show 13 quoted lines

> > to point to. But the configuration would still affect how "git pull"
> > chooses a branch to fetch and merge.
> > 
> > I.e., you can currently do:
> > 
> >   git push --set-upstream /tmp/t master
> >   git pull ;# pulls from /tmp/t master
> 
> Interestingly, this actually fetches the right branch from the remote. I
> wasn't expecting something like this to work at all.
> 
> Somewhat doubtful that this usage is something you'd really want to do,
> I see that it does behave properly.

I do not claim to have used it myself. Tightening the "--set-upstream" behavior would not hurt people who want to configure such a thing manually, and it might catch errors from people doing it accidentally.

So even though the config it generates is not nonsensical, there is a reasonable chance it was an error, and tightening may make sense. But I think you would not want the condition to be "this is a named remote", but rather "the generated configuration actually has an @{upstream}".

-Peff