Glen Choo <chooglen@xxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Glen Choo <chooglen@xxxxxxxxxx> writes: >> >>> Yes, I mean that even the current directory will be ignored when >>> discovery is disabled. >> >> OK. >> >>>> I am not sure that >>>> is realistically feasible (I am thinking of cases like "git fetch" >>>> going to the remote repository on the local disk that is bare to run >>>> "git upload-pack"), but if the fallout is not too bad, it may be a >>>> good heuristics. >>> >>> Good detail - I hadn't considered the impact on our own child processes. >>> I suspect this might be a huge undertaking. Unless there is significant >>> interest in this option, I probably won't pursue it further. >> >> I do not necessarily think so. The entry points to transport on the >> server side are quite limited (and the client side is dealing with >> your own repositories anyway), and they already know which directory >> in the server filesystem to hand to the upload-pack and friends, so >> it would be a matter of passing GIT_DIR=$there when they call into the >> run_command() API, if they are not already doing so. > > FWIW I experimented with turning off bare repo recognition altogether > and seeing what breaks. > > CI Run: https://github.com/chooglen/git/runs/6042600953?check_suite_focus=true > > AFAICT, most of the test failures are what we'd expect if we stopped > recognizing bare repos altogether. One stands out to me in particular > though - in t5550-http-fetch-dumb.sh, > > git clone $HTTPD_URL/dumb/repo.git clone-tmpl > > yields > > ++ 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. > But I'm not that familiar with the transport code so I don't know if > this is a big deal or just a quirk with our httpd tests. Ok I think this is a false alarm - the previous test does some setup on the server, which is a bare repo. It was the _setup_ that was broken, not the actual `git clone`.
