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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2007, 22:39 UTC
Message-ID: <7vve87142z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0711120950370.4362@racer.site>

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

Show 18 quoted lines

> 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.