Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - 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
