Re: [PATCH] status&commit: Teach them to show commits of modified submodules.

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 12 Nov 2007, Johannes Sixt wrote:
>
>> Junio C Hamano schrieb:
>>
>> > I am not saying that it is wrong to use submodule to track such groups 
>> > of source trees whose versions are very closely tied together.  At 
>> > least not yet.
>> 
>> In KDE, the supermodule will actually just be a container that binds the 
>> submodules together. The essential development will happen in the 
>> submodules, and the supermodule will receive a commit quite frequently. 
>> In this case, there will often be only a few or a few dozen commits 
>> listed, and I anticipate that the integrator who is going to make the 
>> commit (to the supermodule) will probably like the summary. So I'm all 
>> for it.
>
> I like it, too.  And we can make the number of shown commits configurable, 
> just like for the merge summary.

Very good point.  In the case J6t uses for his illustration
above, changing the submodule bound to the superproject is more
or less like merging.

> But I'd rather see the code in wt-status.c than in
> git-submodule.sh.

I do not have a strong preference either way, but submodule-loving
people may want to say "git submodule shortlog <path>" or whatever
from the command line.  

Making a standalone function that takes two commits from the
subproject and produces the output, and calling that function
from both git-submodule (to implement the above "shortlog"
subcommand) and from wt-status.c (to show what Yin wants to add,
only when "status.submodule" is set), would be a reasonable
implementation.