Re: [PATCH/RFC] Allow "git remote --mirror" to mirror stashes

On Sun, 30 Mar 2008, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

On Thu, 27 Mar 2008, Junio C Hamano wrote:

Maybe it shouldn't do any filtering here, and instead do it in 
cmd_fetch_pack?

I dunno.  How would the code look like?

Actually, I don't see any reason to call check_ref_format. The point of 
filter_refs is to make sure that we don't fetch anything we didn't ask 
for. We shouldn't care at all about the name of the refs we're considering 
except whether there's in the list to fetch, and if the user requests the 
objects for a ref named 'refs/*^&+' and the server offers such a ref, 
there's no reason for us not to get the objects. (Sure, we shouldn't 
create the ref with that name, but this code path doesn't go on the create 
refs based on these names, except when it's already checking their format 
for that purpose anyway.)

So I'd say just drop the first "if" in that sequence entirely. The only 
thing that could be a problem we'd want to stop here is something that 
would break the packet protocol, and we've already gotten these values 
over the packet protocol anyway.

quoted

This is also true, although I'm not too sure that we won't want to do 
things like having "refs/default" in a public repository be the 
repository's suggestion for the default branch (to replace "HEAD", 
because, in a world where people use lots of branches, the "current 
branch" idea and the "default branch" idea aren't really the same idea, 

In a public repository with many branches to serve people with different
interests, I do not think a single refs/default in addition to HEAD would
help that much.  We would _not_ want to have more magic refs like HEAD.

Quite the opposite.  In such a repository, HEAD means even less, and
instead of giving an extra layer of indirection, you tell people which
branches are what in your repository.  "If you are interested in only the
bugfixes without any new features since the last feature lease no matter
how solid and tested they are, use 'maint' branch.  If you want solid and
tested features, and do not mind new features, use 'master'.  Etc.".

It's not a particularly *useful* default, but "git-clone" presumably 
should initially check out *something* given a repository with multiple 
branches and no local user guidance. And, if this is the git.git 
repository, and you briefly check out each branch in turn to build it when 
you push new changes, then HEAD is usually master but briefly, rarely, and 
irrelevantly other things.

I'm not convinced that it's something worth actually implementing. But I 
think it's a plausible enough idea that we shouldn't exclude the 
possibility of one-level public refs. There are various usues people find 
for this sort of low-semantics pointer on FTP sites, so it could be useful 
in git as well.

	-Daniel
*This .sig left intentionally blank*