On 8/30/07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > That reminds me that gitweb has no support for detached HEAD as of yet, > > although I don't think we want to encourage detached HEAD in public > > repo. > > That logic is flawed, I am afraid. If you have been talking > only about serving public repository via gitweb, then the topic > of the thread becomes totally moot. Exposing or even having > remotes/ in public distribution point repository would be even > more wrong than using detached HEAD in public repository. Other > people who interact with you should not have any business what > you happened to have fetched from _your_ upstream --- if you > want to publish them and act as a relay for your downstream, > then they should be fetched from your branch namespace. OTOH, having 'origin' exposed, and knowing the 'origin' URL, would open lots of interesting fields of research, such as distributed git mirroring to download large repositories from more than a client etc. Anyway, making visible remotes an option that defaults to disabled would address both the issue above and the one below: > But obviously people use gitweb/instaweb as a way to view their > own live repository, and I think it makes sense to show and > support remotes/ in such a case. It also would make sense to > support detached HEAD there as well. If I understand correctly, a detached HEAD is simply a checkout in the middle of a branch, and thus not named. So what exactly are we looking for when we talk about supporting a detached HEAD? Would it be enough to display HEAD in the list of heads? -- Giuseppe "Oblomov" Bilotta - 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
