Hi, On Sat, 2 Jan 2010, Jens Lehmann wrote: > Now that we have much better output when displaying diffs of submodules > in git gui and gitk (many thanks to all involved!), another usability > issue shows up: A dirty working directory of a submodule isn't visible > in git gui or gitk. > > So you might think a "submodule update" would be ok - as you see no > changes - just too see it fail because the submodules working directory > is dirty. > > Or - even worse - you /think/ you committed your changes in a submodule > while you didn't. That can lead to 'interesting' problems which can be > pretty hard to diagnose (like breaking builds on other peoples > machines). > > > A possible solution could look like this: > > AFAICS, git gui and gitk use "git diff-files" both to get the file names > of unstaged local changes and to later display the actual differences. > > If they could tell the diff core to also check the submodule working > directories and to output an extra line - maybe something like > "Submodule <name> contains uncommitted local changes" - when a > submodules working directory is dirty, git gui and gitk could show the > submodules state adequately. The real problem is that submodules in the current form are not very well designed. For example, a submodule being at a different commit than in the superproject's index is not as fatal as the submodule having changes. So in the long run, IMHO a proper redesign of the submodules would not make only a little sense (it does not help, though, that those who implemented and furthered the current approach over other discussed approaches do not use submodules themselves -- not even now). In ths short run, we can paper over the shortcomings of the submodules by introducing a command line option "--include-submodules" to update-refresh, diff-files and diff-index, though. The implementation might be a bit tricky as parts of Git's source code still use the_index, but at least adding the submodule's object database is no longer that difficult. Ciao, Dscho -- 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