Chris Frey <cdfrey@xxxxxxxxxxxxxx> writes: > It's true that subproject X has to be able to stand on its own. That > is important from git's perspective as well as for managing subprojects > in general. > > But I don't see the advantage in hiding submodule information from the > supermodule, and if that hiding is by design, I think the design is wrong. There is no "wrong" design in git. There are ones that do not cover 360 degrees of the field, because nobody designed out let alone coded to cover such use cases. > In order to manage the various modules effectively (actually, in order to > manage any git repo effectively), you need to know what's changed, > and git-status is the way to do that. I don't see why submodules should > break that. Changes to parts of submodules are fundamentally different from changes to parts of your main project. A change to what commit the superproject wants for a submodule is at the same level as a change to what content the superprojects wants for a blob. It is not unreasonable to want to have both modes of operation, one that shows the uncommitted details in the submodule even when you are viewing from the superproject (which does not exist), and one that does not (which does exist, because somebody felt need for it and coded so). In order to see the status of your working tree, you may want to take into account what untracked files are in there, but some people do not want to, so there is an option to pick which behaviour you want. We would need a similar switch. > With the new submodule foreach command, though, it should be possible > to add that as a config option, similar to the way submodule summary > is handled now. Maybe I can cook up a patch for that. Yup, that's the spirit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
