On Mon, Aug 30, 2021 at 1:38 AM David Aguilar <davvid@xxxxxxxxx> wrote: > I hope that helps and maybe sparks an idea that you can run with. I > certainly don't mean it to be a dismissive, "go change your setup" > kind of advice, but it would be interesting to know more details since > it seems like achieving correctness is going to require doing that > based on the limited information in this thread about the specifics of > the setup. > > Also, I wouldn't be surprised if, even after the "git ls-remote" > robustness fixes are applied, you'll just stumble onto the next git > command that can only be resolved by mapping in the parent repo's .git > directory. We map the source code into a build tree in order to build executables. We don't expect to be using git on that build tree. But one of our executables is written in go and uses go modules. In our situation, `go mod download` was trying to use `git ls-remote` to inspect dependencies before downloading them with `git clone`, swallowing the git error and then dying horribly on something else that appeared to be unrelated. I raised a related bug report on `go` (I think I linked it elsewhere in this thread). So for us, easily the worst thing about these two related bugs was just figuring out what was wrong in the first place, and the go bug was definitely more severe than the git bug. We could modify our build system to make the git local repo valid but there just doesn't seem any point - we never do anything to the local repo in the build tree. The next engineer who comes along and looks at our build system would inevitably ask why on earth we need to make git work in the build tree and it would be a fair question. As an end user, it still appears to make little sense for a git operation that will complete happily with no local git repo at all and which doesn't depend on the local repo in any way to nonetheless die because the local repo is not valid. As a software engineer I can see why it's that way but as a user it's unhelpful. Regards, Tom
