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