On Tue, 20 Oct 2009, Sean Estabrooks wrote: > On Tue, 20 Oct 2009 20:15:23 -0400 (EDT) > Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > Hi Daniel, > > > Surely, "where you want the head stored locally" is somewhere that's > > information about a remote repository, and therefore under "refs/remotes/" > > (or "refs/tags/" or something) and therefore not possible to be checked > > out (in the "HEAD is a symref to it" sense). > > Maybe, but it could also just be to create a temp local branch for > merging into additional branches afterward with "checkout other; > merge temp". This is especially helpful when pulling from an > annoyingly long URL instead of from a configured remote. Maybe it should be fine to do: $ git fetch long-url-here master:temp $ git merge temp $ git checkout other-branch-that-also-needs-it $ git merge temp But "temp" is "refs/remotes/temp", not "refs/heads/temp"? > > Actually, I think it would be good to prohibit fetching into a new or > > existing local branch, whether or not it is checked out. We'd probably > > need to provide a plumbing method of doing a fetch, though, for script > > environments that aren't using the normal porcelain meanings of refs/ > > subdirectories. (Defining a bare repo with --mirror as not having local > > branches, of course) > > I'm hoping you don't mean that all fetching to a new local branch should > be prohibited and you're only talking about the current issue of full > refspecs on and the pull command. Otherwise i'd say it seems > unnecessarily restrictive. I think, actually, that creating or changing a local branch is really not what "fetch" (or the fetch part of pull) is about. I think that just leads to confusion about what's locally-controlled and what's a local memory of something remotely-controlled. -Daniel *This .sig left intentionally blank* -- 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