Linus Torvalds wrote:
So I actually think that submodules should at least start out as something rather independent, where a "commit -a" in the supermodule will _only_ commit the supermodule itself - and if you haven't committed the submodule yet, you'll just get the current HEAD state of the submodule.
That would make it impossible to atomically commit a change that affects two submodules, yes? I think cross-submodule commit is highly desirable and will be a fairly common use case for submodules if it's supported. For example, if you have "client" and "server" submodules and someone makes a protocol change, you don't want some unwitting developer to pull just half of the change and end up with incompatible code in the two submodules.
I have no problem with making the "only commit the supermodule" behavior the default and requiring a command-line option for the "commit everything" case, but I think "commit everything" is useful. And honestly IMO it should be the default since it'll behave in a less surprising way; when I do a "commit -a" I expect all my changes to be committed, whether they're in submodules or not.
-Steve - 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