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. > I don't think it should be possible to fast-forward or create a local > branch from a remote branch while simultaneously merging it into the > currently-checked-out local branch. What is the harm? Nobody is forced to use the facility and it does have some marginal utility. I'd not fight for it, but i don't yet understand the argument to prohibit it. > 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. Cheers, Sean -- 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