On Thu, 27 Mar 2008, Junio C Hamano wrote: > When you have "remote.$there.fetch = refs/*:refs/*" and the remote has a > ref directly under refs/ (e.g. "stash"), "git fetch" still errored out > even with fixes in -rc1. In particular, it would fail to request "refs/stash", and then be surprised that it didn't get the object that points to. (This would be a helpful thing to mention in the commit message) > This should hopefully fix it. Maybe it shouldn't do any filtering here, and instead do it in cmd_fetch_pack? If the transport code gets to this point and anything gets filtered out by this function, the transport code or builtin-fetch will have to be terribly confused and fail with a mysterious error message, AFAICT. > * Rather than failing, it would be better to allow "git fetch" to succeed > by doing this, but on the other hand, stash is purely a local matter, > so it might make more sense to avoid exposing it from the uploader. 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, although there's no technical conflict since only one of these ideas is really important in any given repository). So we probably want a whitelist or blacklist for refs to serve when we avoid exposing things in the uploader, rather than using the level, in which case it's definitely important to have fetch-pack just ignore stuff. -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
