On Mon, Nov 20, 2017 at 03:37:03PM -0500, Jeff King wrote: > On Mon, Nov 20, 2017 at 12:28:11PM -0800, Stefan Beller wrote: > > > > +cc Stefan, who added the die(). It may be that we don't care that much > > > these days about recovering from broken .gitmodules files. > > > > By that you mean commits like 37f52e9344 (submodule-config: > > keep shallow recommendation around, 2016-05-26) for example? > > That adds a git_config_bool to the submodule config machinery. > > I actually meant ea2fa5a338 (submodule-config: keep update strategy > around, 2016-02-29), which adds an actual die() into parse_config(). But > yeah, I think the end result is the same. > > > I agree that we'd want to be more careful, but for now I'd put it to the > > #leftoverbits. > > Fine by me. While I think the original intent was to be more lenient to > malformed .gitmodules, it's not like we're seeing bug reports about it. My original intent was not about being more lenient about malformed .gitmodules but having a way to deal with repository history that might have a malformed .gitmodules in its history. Since depending on the branch it is on it might be quite carved in stone. On an active project it would not be that easy to rewrite history to get out of that situation. When a .gitmodules file in the worktree is malformed it is easy to fix. That is not the case when we are reading configurations from blobs. My guess why there are no reports is that maybe not too many users are using this infrastructure yet, plus it is probably seldom that someone edits the .gitmodules file by hand which could lead to such a situation. But if such an error occurs it will be very annoying if we die while parsing submodule configurations. The only solution I see currently is to turn submodule recursion off completely. But maybe I am being overly cautious here. Cheers Heiko
