Re: [PATCH] pull: refuse complete src:dst fetchspec arguments

On Tue, 20 Oct 2009, Sean Estabrooks wrote:

On Tue, 20 Oct 2009 20:23:06 +0200
Thomas Rast [off-list ref] wrote:

Hi Thomas,

quoted

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*