On Sun, 30 Mar 2008, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > 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. > > 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* -- 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
