Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 06.01.2010 21:01, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> Am 06.01.2010 18:55, schrieb Junio C Hamano:
>>> I was envisioning that the "git status" in submodule will be run with its
>>> recent --porcelain option, and "git status" or "git commit" would read it
>>> to postprocess and incorporate into its own output.
>>
>> And i thought about printing just one line for each dirty submodule that
>> contains uncommitted and/or new files. I did not intend to list every
>> file, for the same reason a "git diff --submodule" only shows the first
>> line of the commit messages, not the actual differences of all changed
>> files in the submodule. I am not against being able to show all files
>> too, but i really would want to have an option to get a short output for
>> git gui and gitk.
> 
> I don't think what you are saying is inconsistent with "git status/commit
> that reads from 'git status --porcelain' it runs in a submodule directory,
> postprocesses it and incorporates it into its own output."  When the
> sub-status reports changes, your "postprocess" would condense it down to
> "this has a potential change that user could want to commit".  How the
> dirtiness is shown is entirely up to the caller that detected that change.
> 
> Let's explain it in another way.
> 
> The original "diff" for a submodule entry was implemented by preparing a
> 
> 	"Subproject commit %s\n"
> 
> line for the submodule commit recorded in the preimage and postimage, and
> compare these as if they are one-line files.  When the postimage was work
> tree, it looked at submodule's .git/HEAD to learn what to stuff in %s
> there.
> 
> But nobody forced you to limit the check only to .git/HEAD in the
> submodule.  To make the comparison richer, you could check if the
> submodule directory is dirty (and we have already discussed the potential
> definition of dirtiness earlier), and add "-dirty" in the string as well.
> With such a change, if you make some changes to a file in the work tree of
> the submodule after a clean "clone", "git diff" between the index and the
> work tree would report:
> 
> 	-Subproject commit 37bae10e38a66e4f1ddd5350daded00b21735126
> 	+Subproject commit 37bae10e38a66e4f1ddd5350daded00b21735126-dirty
> 
> The suggestion to read from "status --porcelain" that is run in the
> submodule directory was about how to implement the part that determines
> this "dirtiness" information, and not about how that dirtiness is
> expressed in the output.  The above is an illustration that even the
> traditional output format can be made aware of this submodule dirtiness
> check.  "diff --submodule" can express that dirtiness information in any
> way it wants.

I see, we seem to agree again :-)

While looking into "git status" in the last hours i became aware that
there is some infrastructure for calling "git submodule summary" (when
that is enabled via "git config status.submodulesummary"). I think this
can be extended to transfer the dirty information from "git diff
--submodule" (which can and should replace "git submodule summary" IMO)
into "git status".

Will send a patch for discussion tomorrow, i have to get some sleep now.