On Tue, Mar 21, 2017 at 3:41 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> AFAICT, someone is (was?) using a version of Git that doesn't contain >> f8eaa0ba98 (submodule--helper, module_clone: always operate >> on absolute paths, 2016-03-31). So then the submodule paths were >> made absolute paths on creation of the Gerrit repo. >> >> And then someone moved the repo and the absolute paths broke. >> >> Even after an upgrade of Git to its latest and greatest version, the >> underlying >> issue of having broken submodule paths remains in that case. >> >> So there are a couple of ways forward >> 0) as an immediate fix, manually fix the absolute path or make them relative >> >> 1A) have more error resilient tools in Git >> 1B) have a tool in git (e.g. "git submodule fsck-setup") that rewrites >> the .git file link and the core.worktree setting to be relative and >> correct. >> >> I think we should do both A and B, I decided to go with A first, specifically >> "git-describe" as that was reported to not work well in this situation with >> the >> given broken data > > Sounds sensible. I would say that we should do less 1A (i.e. hiding > problems under the rug) and more 1B. Of course, making the problem > less likely to happen in the first place would be more important ;-)
Agreed on not introducing bugs as often. For (B), I wonder what the right place is. Maybe "reset --hard", in combination with "--recurse-submodules" would also fix these submodule path issues. The made up "git submodule fsck-setup" sounds like it would only detect (and not fix) the problems. But these absolute paths issues are known how to fix, so a "fsck"-y tool may convey a wrong impression.
