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

From: Sean Estabrooks <seanlkml@sympatico.ca>
Date: Oct 21, 2009, 00:29 UTC
Message-ID: <BLU0-SMTP889B2109047E949E039EFDAEBF0@phx.gbl>
In-Reply-To: <alpine.LNX.2.00.0910202001050.14365@iabervon.org>

On Tue, 20 Oct 2009 20:15:23 -0400 (EDT) Daniel Barkalow <barkalow@iabervon.org> 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.

Show 6 quoted lines

> 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