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

> > 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.

> > 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}".

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

Reply via email to