Glen Choo <chooglen@xxxxxxxxxx> writes: > FWIW I experimented with turning off bare repo recognition altogether > and seeing what breaks. I guess our mails crossed ;-) I've done a similar one locally and sent a report out earlier, and I think the part of the function in question that we disabled is identical. > ++ git clone http://127.0.0.1:5550/dumb/repo.git clone-tmpl > Cloning into 'clone-tmpl'... > fatal: repository 'http://127.0.0.1:5550/dumb/repo.git/' not found > > This sounds to me like Git isn't recognizing the static http files as a > remote Git repo, and if so, --git-dir doesn't sound like it'll save us. If the http server side we ship _depends_ on the fact that we historically consider that it is enough to chdir into a directory to use that directory as a bare repository, it is not all that surprising that the server side infrastructure needs to do an equivalent of "export GIT_DIR=." in addition to chdir it already does into the directory. There may be other things that the http responder in the affected test needs to do before it can recognize that the dumb/repo.git URL refers to a valid bare repository, and until that happens, the above experiment may not start working. I am not worried about that kind for breakage all that much, because it is entirely under _our_ control how an HTTP request received results in a "git" invocation, how "git clone/fetch ssh://" invokes the process that runs "git upload-pack" on the other side in the directory requested, etc. What worries me more is the effect on _other_ people's server implementations ("server", because that is one major class of use case of bare repositories). Essentially they need to identify the places where they depend on the current behaviour (i.e. going to the bare repository is enough to use it) and export GIT_DIR=. when they invoke "git" there. The actual change that is necessary might be small, but identifying the places that need such changes may be added burden to them. Thanks.
