On Tue, 28 Nov 2006, Andreas Ericsson wrote: > Daniel Barkalow wrote: > > On Sat, 25 Nov 2006, Linus Torvalds wrote: > > > I'd actually suggest that "git commit -a" with non-clean submodules error > > > out for that reason > > > > Just have it run "git commit -a" in each dirty submodule recursively as part > > of preparing the index, since that's what the user wants to do anyway, and > > nothing already done would be affected. > > > > Running "commit -a" is definitely the wrong thing to do, as it prevents one > from using the index at all. Erroring out if the submodules are dirty, or just > accepting the fact that they are and taking whatever commit HEAD points to is > *always* preferrable. I don't think anyone would actually use the index in submodules but not in the supermodule. If submodules are seen mostly as ordinary directories as far as the supermodule's working directory is concerned, it wouldn't make sense to not commit dirty state in a subdirectory with -a just because it's a submodule. It would be wrong to do "commit -a" in submodules if the supermodule weren't being committed with -a, of course. > > "git commit -a -m <message>" should probably fail, of course. > > > > Why? There's no reason to rob this command of its power just because we're > using submodules. It should fail if there are dirty submodules, because the user needs to provide a commit message for each of them, and only one commit message can be provided this way, and -m inhibits invoking an editor. -Daniel *This .sig left intentionally blank* - 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