On Tue, Nov 28, 2006 at 01:37:54PM -0500, Daniel Barkalow wrote: > If submodule was the only thing that got changed, it's not dirty; if it > were dirty, some of its contents would also have gotten changed. For me, the commit is the only "content" of the subproject that the superproject should care about, so the submodule being dirty or not is completely irrelevant (for committing), but it seems you see the subproject more as a (working) tree than as a commit. Of course, as Linus already mentioned, a "git commit" could still warn you if the subproject was dirty. > Surely: > > "git commit submodule/foo bar" I wouldn't dream of doing such an operation, because it doesn't make sense to me. (So as far as I'm concerned, you can make it do whatever you'd like it to do.) You can only commit the subproject as a whole. > should do "git commit foo" in submodule, and then commit the supermodule > with the new commit for the submodule and the change to bar. And so > "submodule/foo" is something you could commit changes to, so it should get > picked up by -a. skimo - 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