On Tue, 20 Oct 2009, Sean Estabrooks wrote: > On Tue, 20 Oct 2009 20:23:06 +0200 > Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > > Hi Thomas, > > > git-pull has historically accepted full fetchspecs, meaning that you > > could do > > > > git pull $repo A:B > > > > which would simultaneously fetch the remote branch A into the local > > branch B and merge B into HEAD. This got especially confusing if B > > was checked out. New users variously mistook pull for fetch or read > > that command as "merge the remote A into my B", neither of which is > > correct. > > > > Since the above usage should be very rare and can be done with > > separate calls to fetch and merge, we just disallow full fetchspecs in > > git-pull. > > It is however a handy shortcut to be able to specify the full refspec > and specify where you want the head stored locally. It seems a shame to > throw away that functionality because of one confusing case. Wouldn't > it be better to test of the confusing case and instead error out if the > local refname is already checked out? 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). 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. 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) -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