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

On Tue, 20 Oct 2009, Sean Estabrooks wrote:

On Tue, 20 Oct 2009 20:15:23 -0400 (EDT)
Daniel Barkalow [off-list ref] wrote:

Hi Daniel,

quoted

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"?

quoted

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*