Heiko Voigt <hvo...@hvoigt.net> writes: >> It IS a hack, but having this information in .git<something> would >> mean that it can be forced to be in machine readable form, unlike a >> mention in README. I do not know if the .gitmodules/.gitignore >> combination is a sensible thing to use, but it does smell like a >> potentially useful hack. > > IIRC the tree entries are the reference for submodules in the code. We > are iterating over the tree entries in many places so that change does > not seem so easy to me. > > But you are right maybe we should stop arguing against this workflow and > just let people use it until they find out whats wrong with it ;)
I didn't say that, though. I am fairly firm on _not_ changing what the superproject records in its tree for the submodule, i.e. it must record the exact commit, not "a branch name", for reproducibility. I am OK if people ignored the unmatch between the recorded commit from a submodule and what they had in the submodule directory while they developed and tested the superproject commit. After all, it is not an error to make a commit while having a local uncommitted changes to tracked files, and it is equally valid to have a commit checked out in a submodule directory that is different from what goes in the superproject commit. But we do show "modified but not committed" in the status output. In that light, submodule.*.ignore may have been a mistake.
