Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:47:58
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