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

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

quoted

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.

quoted

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