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

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

[Ping Yin]

git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how submodules change (the commits).

This commit teaches git status/commit to also show commits of user-cared
modified submodules since HEAD (or HEAD^ if --amend option is on).
Notes:
	1. Submodules already checked out are considered to be user-cared ones.
	2. For submodules deleted or initially added, commits are not shown.

For example, when commiting, submodule sm1 and sm2 are both changed. sm1 has
commit C in HEAD and commit E in index. The history of sm1 is
	--A-->B-->C (in HEAD:354cd45)
	  \
	   -->D->E (in index:3f751e5)

git status will give the following output (just output commits of submodules
before the original output) to show how to change from commit C (in HEAD) to
commit E (in index) for submodule sm1: backward ('<<<') to commit A, and then
forward ('>>>') to commit E. Similar illustration for output of sm2 is omitted.

	#
	# submodule modifiled: sm1 sm2
	#
	# * sm1 354cd45...3f751e5:
	#   <<<
	#   	one line message for C
	#   	one line message for B
	#   >>>
	#   	one line message for D
	#   	one line message for E
	#
	# * sm2 5c8bfb5...ac46d84:
	#   <<<
	#   	msg
	#
	# On branch master
	# Changes to be committed:
	#   (use "git reset HEAD <file>..." to unstage)
	#
	#	modified:   sm1
	#	modified:   sm2

For sm1, if the commit recorded in HEAD/index (say commit C/E) is not found in
the work tree (say sm1 respository in the work tree), a warning will be issued.

	#
	# submodule modifiled: sm1
	#
	# * sm1 354cd45...3f751e5:
	#   Warn: sm1 doesn't contains commit 354cd45
	#
	# On branch master
	# Changes to be committed:
	#   (use "git reset HEAD <file>..." to unstage)
	#
	#	modified:   sm1

Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
 git-commit.sh |   68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..29f2ebe 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,68 @@ save_index () {
 	cp -p "$THIS_INDEX" "$NEXT_INDEX"
 }
 
+# Show log of modified submodule (index modification since HEAD or $1)
+# $1 is the commit to be compared, default 'HEAD'
+show_module_log () {
+	cwd=$(pwd)
+	cd_to_toplevel 
+
+	# get modified modules which have been checked out (i.e. cared by user)
+	modules=$(git diff --cached --name-only $1 |
+	(
+		IFS=''	# handle the module name containing space or tab
+		while read name
+		do
+			git ls-files --stage "$name" | grep '^160000 ' >&/dev/null &&
+			GIT_DIR="$name/.git" git-rev-parse --git-dir >&/dev/null &&
+			echo "$name"
+		done
+	)
+	)
+
+	# TODO: quote module names containing space or tab
+	test -n "$modules" && echo -e "#\n# submodule modifiled: "$modules"\n#"
+	OLDIFS=$IFS
+	IFS=$'\n\r'	# '\r' for mac os 
+	for name in $modules
+	do
+		range=$(git diff --cached -- "$name" | sed -n '/^index.*160000$/ p' | awk '{print $2}')
+		indexone=${range#*..}
+		headone=${range%..*}
+		(
+			echo "* $name $headone...$indexone:"
+			headfail=
+			indexfail=
+			GIT_DIR="$name/.git" git-rev-parse $headone >&/dev/null || headfail='t'
+			GIT_DIR="$name/.git" git-rev-parse $indexone >&/dev/null || indexfail='t'
+			case "$headfail,$indexfail" in
+			t,)
+				echo "  Warn: $name dosn't contains commit $headone"
+				;;
+			,t)
+				echo "  Warn: $name dosn't contains commit $indexone"
+				;;
+			t,t)
+				echo "  Warn: $name dosn't contains commits $headone and $indexone"
+				;;
+			*)
+				left=$(GIT_DIR="$name/.git" git log --pretty=oneline $indexone..$headone 2>&1 |
+				sed 's/^\w\+ /  \t/')
+				right=$(GIT_DIR="$name/.git" git log --pretty=oneline --reverse  $headone..$indexone 2>&1 |
+				sed 's/^\w\+ /  \t/')
+
+				test -n "$left" && echo -e "  <<<\n$left"
+				test -n "$right" && echo -e "  >>>\n$right"
+				;;
+			esac
+			echo
+		) | sed 's/^/# /'
+	done
+	IFS=$OLDIFS
+
+	cd "$cwd"
+}
+
 run_status () {
 	# If TMP_INDEX is defined, that means we are doing
 	# "--only" partial commit, and that index file is used
@@ -55,6 +117,12 @@ run_status () {
 	else
 		color=--nocolor
 	fi
+	if test -z "$amend"
+	then
+		show_module_log
+	else
+		show_module_log "HEAD^"
+	fi
 	git runstatus ${color} \
 		${verbose:+--verbose} \
 		${amend:+--amend} \
-- 
1.5.3.4

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

[Sven Verdoolaege]

On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:
> This commit teaches git status/commit to also show commits of user-cared

Does it?  It looks like you only changed git-commit.
Shouldn't this be put in wt_status_print, if anywhere?

Also, you have some typos:

> +	test -n "$modules" && echo -e "#\n# submodule modifiled: "$modules"\n#"
[..]
> +				echo "  Warn: $name dosn't contains commit $headone"

skimo

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

[Sven Verdoolaege]

On Sat, Nov 10, 2007 at 08:55:09PM +0100, Sven Verdoolaege wrote:
> On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:
> > This commit teaches git status/commit to also show commits of user-cared
> 
> Does it?  It looks like you only changed git-commit.

OK.  Never mind about this one.

skimo

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

[Yin Ping]

On Nov 11, 2007 3:55 AM, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:
> > This commit teaches git status/commit to also show commits of user-cared
>
> Does it?  It looks like you only changed git-commit.
> Shouldn't this be put in wt_status_print, if anywhere?
>
git-commit and git-status correspond to the same script git-commit.sh
> Also, you have some typos:
>
> > +     test -n "$modules" && echo -e "#\n# submodule modifiled: "$modules"\n#"
> [..]
> > +                             echo "  Warn: $name dosn't contains commit $headone"
>
> skimo
>
Oops, i'll fix it



-- 
Ping Yin

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

[Junio C Hamano]

Ping Yin <pkufranky@gmail.com> writes:

> 	# submodule modifiled: sm1 sm2
> 	#
> 	# * sm1 354cd45...3f751e5:
> 	#   <<<
> 	#   	one line message for C
> 	#   	one line message for B
> 	#   >>>
> 	#   	one line message for D
> 	#   	one line message for E
> 	#
> 	# * sm2 5c8bfb5...ac46d84:
> 	#   <<<
> 	#   	msg
> 	#
> 	# On branch master
> 	# Changes to be committed:
> 	#   (use "git reset HEAD <file>..." to unstage)
> 	#
> 	#	modified:   sm1
> 	#	modified:   sm2

I think this presentation order is horrible.

 * I think everbody preferes to have "On branch master" at the
   very beginning, to avoid committing to a wrong branch by
   mistake.

 * As I understand it, in the real life use, there will be quite
   many commits from the submodule updates when a new commit is
   bound to a submodule in the superproject, as _the_ point of
   having a submodule is to bind a more or less independent
   project that progresses at quite a different pace as a
   submodule to the superproject.  In other words, by design,
   the superproject can stay behind from the tip of subproject
   and rebind it to a different commit only when there are
   significant changes of the subproject that need to be there
   to allow the other parts of the superproject (either
   superproject itself or another submodule) to use the features
   and/or fixes the submodule updates provides.

   Which means it will not be uncommon have hundreds of "one
   line message" for the submodules at the very beginning of the
   commit log message buffer, and your prsentation order will
   make that part overwhelm the overview of what changed _in_
   the supermodule itself (the "Changes to be committed:"
   lines), which gives the birds-eye view.

   And I think it is more important to give the birds-eye view
   of the supermodule itself first, when you are helping to
   prepare a commit message for the supermodule.  The user would
   start the commit log for the superproject with "This updates
   the new frotz feature.  It uses the updated API from the
   submodules A and B so we now use updated versions of them."
   and then continue "Notable changes in submodule A are ...".
   And the new part you are adding would help the user to write
   the latter description.

I also find "<<< lines then >>> other lines" format very hard to
read.  Maybe formatting it like this would make it a bit more
readable and more space efficient?

 	# * sm1 354cd45...3f751e5:
 	#   - one line message for C
 	#   - one line message for B
 	#   + one line message for D
 	#   + one line message for E
 	# * sm2 5c8bfb5...ac46d84:
 	#   - msg

Note that if you swap the order and move this at the tail
(perhaps before "Untracked files:" section, if you do not have a
decent .gitignore set up), you can also lose the "submodules
modified: sm1 sm2" line and the blank line before it, which
would make the output even shorter without losing any useful
information.

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

[Yin Ping]

On Nov 11, 2007 5:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  * I think everbody preferes to have "On branch master" at the
>    very beginning

Reasonable.

>
>  * As I understand it, in the real life use,
>    the superproject can stay behind from the tip of subproject
>    and rebind it to a different commit only when there are
>    significant changes of the subproject that need to be there
>    to allow the other parts of the superproject (either
>    superproject itself or another submodule) to use the features
>    and/or fixes the submodule updates provides.

I think it's this kind of case in most open-source project. However,
in a company environment, superprojects may be not so super. A
superproject may bind very tightly with submodules (such as the html
template files which change very frequently) and the developer of a superproject
and its submodules may be the same guy(s). In these cases, a long list
of commits
for submodules are expected be reviewed when commiting the superproject.
>
>    And I think it is more important to give the birds-eye view
>    of the supermodule itself first, when you are helping to
>    prepare a commit message for the supermodule.
>    and then continue "Notable changes in submodule A are ...".
>    And the new part you are adding would help the user to write
>    the latter description.
I agree.
>
> I also find "<<< lines then >>> other lines" format very hard to
> read.  Maybe formatting it like this would make it a bit more
> readable and more space efficient?
>
>         # * sm1 354cd45...3f751e5:
>         #   - one line message for C
>         #   - one line message for B
>         #   + one line message for D
>         #   + one line message for E
>         # * sm2 5c8bfb5...ac46d84:
>         #   - msg
>
I have struggled between these two kinds of presentation and finally
choose the '<<<' one.
IMHO, '-/+' one each line will distract and less space/size efficient
(100 '+/-' for 100 lines of messages).

However, it's not a big matter. I'll change the presentation if
everyone prefers the
patch-like one.

> Note that if you swap the order and move this at the tail
> (perhaps before "Untracked files:" section, if you do not have a
> decent .gitignore set up), you can also lose the "submodules
> modified: sm1 sm2" line and the blank line before it, which
> would make the output even shorter without losing any useful
> information.
>
So following is ok?
        # On branch master
        # Changes to be committed:
        #   (use "git reset HEAD <file>..." to unstage)
        #
        #       modified:   sm1
        #       modified:   sm2
        #       modified:   sm3
        #
        # Changed but not updated:
        #   (use "git add/rm <file>..." to update what will be committed)
        #
        #       modified:   file1
        #
        # Submodules modifiled: sm1 sm2 sm3
        #
        # * sm1 354cd45...3f751e5:
        #   - one line message for C
        #   - one line message for B
        #   + one line message for D
        #   + one line message for E
        # * sm2 354cd46...3f751e7:
        #   - one line message
        # * sm3 354cd47...3f751e8:
        #   Warn: sm1 doesn't contains commit 354cd45
        #
        # Untracked files:
        #   (use "git add <file>..." to include in what will be committed)
        #
        #       file2
        #



-- 
Ping Yin

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

[Junio C Hamano]

"Yin Ping" <pkufranky@gmail.com> writes:

> I think it's this kind of case in most open-source project. However,
> in a company environment, superprojects may be not so super.

Let's not say "most open-source" nor "company", because I think
nobody said anything that substantiates that the commit density
characteristics I described is typical for most open-source, nor
what you said is typical for corporate development projects, in
this thread so far.

If "superprojects is not so super", why are you using submodule
to bind these, instead of using a single project that tracks
developments of such closely tied parts?

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.

I am just trying to find out what benefit you are getting out of
the submodule support, after rejecting one of the most visible
and advertised benefit of submodule support, which is to enable
binding "related but not that closely tied together" projects.

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

[Ping Yin]

On Nov 12, 2007 4:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> If "superprojects is not so super", why are you using submodule
> to bind these, instead of using a single project that tracks
> developments of such closely tied parts?
>
For small modules crossing over mutiple projects, the submodule way
may be more suitable. And such submodule (such as common config files,
common templates) may be binded tightly with superproject

>



-- 
Ping Yin

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

[Johannes Sixt]

Junio C Hamano schrieb:
> "Yin Ping" <pkufranky@gmail.com> writes:
> 
>> I think it's this kind of case in most open-source project. However,
>> in a company environment, superprojects may be not so super.
> 
> Let's not say "most open-source" nor "company", because I think
> nobody said anything that substantiates that the commit density
> characteristics I described is typical for most open-source, nor
> what you said is typical for corporate development projects, in
> this thread so far.
> 
> If "superprojects is not so super", why are you using submodule
> to bind these, instead of using a single project that tracks
> developments of such closely tied parts?

Because the a monolithic project is just too large? Think of KDE!

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

-- Hannes

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

[Johannes Schindelin]

Hi,

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.  But I'd rather see the code in 
wt-status.c than in git-submodule.sh.

Ciao,
Dscho

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

[Junio C Hamano]

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. 

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

[Johan Herland]

On Sunday 11 November 2007, Junio C Hamano wrote:
> "Yin Ping" <pkufranky@gmail.com> writes:
> 
> > I think it's this kind of case in most open-source project. However,
> > in a company environment, superprojects may be not so super.
> 
> Let's not say "most open-source" nor "company", because I think
> nobody said anything that substantiates that the commit density
> characteristics I described is typical for most open-source, nor
> what you said is typical for corporate development projects, in
> this thread so far.
> 
> If "superprojects is not so super", why are you using submodule
> to bind these, instead of using a single project that tracks
> developments of such closely tied parts?
> 
> 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.
> 
> I am just trying to find out what benefit you are getting out of
> the submodule support, after rejecting one of the most visible
> and advertised benefit of submodule support, which is to enable
> binding "related but not that closely tied together" projects.

At $dayjob, we are working on a codebase roughly the same size as current 
linux-kernel with about 8 years of history in CVS. I'm currently looking at 
how suitable git would be for our revision control purposes (and so far I'm 
lovin' it).

The codebase is divided into CVS modules; most modules (aka. "core" modules) 
each have their own in-house maintainer and have internal releases with 
variable frequency. The other modules (aka. "platform/product" modules) 
each pull together a carefully chosen set of "core" modules as submodules, 
and add platform code to create - in the end - a complete product (with its 
own release frequency). Specifically:

- All the modules required by the product must be present in the checkout 
before a build can be made

- All the modules are independently developed, with different 
development/release timelines

- The "core" people only focus on 1-2 modules at a time, but 
the "platform/product" people might make changes in _many_ modules during a 
workday.

When investigating how to mesh this workflow with git, I naturally ended up 
with converting each CVS module to a git repository, and making 
the "platform/product" repos include the required "core" repos as 
submodules. This decision has the following effect from git's POV:

- "superproject is not so super" in that _all_ required modules must be 
checked out before a build can be made. In other words: all the submodules 
in a repo are "interesting"

- The modules are "related but not that closely tied together" since they 
follow separate development schedules, with separate releases, etc.

- The "platform/product" people will most certainly want to have commands 
like "git diff", "git status", and maybe even "git log" and "git-commit" 
recurse into submodules.

- The "core" people will probably not want "recurse-into-submodules" 
behaviour, although I can see places where it could be useful for them as 
well.


A possible solution to the above problem is to add 
a '--recurse-into-submodules' option to all relevant git commands. At the 
same time, the actual implementation of submodule recursion should probably 
be kept in the vicinity of "git-submodule" (instead of spreading it across 
the other git commands).

Probably unrealistic: Maybe we could solve the problem by adding
"--recurse-into-submodules" to the toplevel 'git' command itself, and make 
it re-invoke itself recursively in each submodule.


Hope this gives you insight into how _some_ people would like to use git's 
submodule support.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

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

[Johannes Sixt]

Junio C Hamano schrieb:
> I also find "<<< lines then >>> other lines" format very hard to
> read.  Maybe formatting it like this would make it a bit more
> readable and more space efficient?
> 
>  	# * sm1 354cd45...3f751e5:
>  	#   - one line message for C
>  	#   - one line message for B
>  	#   + one line message for D
>  	#   + one line message for E
>  	# * sm2 5c8bfb5...ac46d84:
>  	#   - msg

How about the equivalent of

	git log --left-right --pretty=oneline --topo-order 354cd45...3f751e5

which would be

   	# * sm1 354cd45...3f751e5:
   	#   <one line message for C
   	#   <one line message for B
   	#   >one line message for D
   	#   >one line message for E

-- Hannes

[PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how submodules change (the commits).

This commit teaches git status/commit to additionally show commit summary of
user-cared (i.e. checked out) modified submodules since HEAD (or HEAD^ if
--amend option is on). For submodules deleted or initially added, commit summary
are not shown.

A configuration variable 'submodule.status' is used to turn this summary
behaviour on or off (default off). Also --submodule and --no-submodule options
are added.

By introducing this commit, git status will additionally give
'Submodules modified' section just before 'Untracked files' section as the
following example shows.

	# On branch master
	# Changes to be committed:
	#   (use "git reset HEAD <file>..." to unstage)
	#
	#	modified:   sm1
	#	modified:   sm2
	#	modified:   sm3
	#	deleted:    sm4
	#
	# Submodules modifiled: sm1 sm2 sm3
	#
	# * sm1 354cd45...3f751e5:
	#   <one line message for C
	#   <one line message for B
	#   >one line message for D
	#   >one line message for E
	#
	# * sm2 5c8bfb5...ac46d84:
	#   <msg
	#
	# * sm3 354cd45...3f751e5:
	#   Warn: sm3 doesn't contains commit 354cd45
	#
	# Untracked files:
	#   (use "git add <file>..." to include in what will be committed)
	#
	#	file1

This superproject shown has modified/deleted submodules sm1 to sm4.

sm1 has commit C in HEAD and commit E in index. The history of sm1 is
	--A-->B-->C (in HEAD:354cd45)
	  \
	   -->D-->E (in index:3f751e5)

The 'Submodules modified' section for sm1 shows how to change sm1 from commit C
(in HEAD) to commit E (in index): backward (<) to commit A first, and then
forward (>) to commit E.

Similar illustration for output of sm2 is omitted.

If the commit recorded in HEAD/index for a submodule is not found in the work
tree (say the submodule respository in the work tree), a warning will be issued.
Submodule sm3 falls into this case.

Commits of sm4 are not shown since it's a deleted submodule.

Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
 Documentation/git-commit.txt |   10 +++++
 Documentation/git-status.txt |    3 +
 git-commit.sh                |   90 ++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 99 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..0680a57 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -139,6 +139,13 @@ but can be used to amend a merge commit.
 -q|--quiet::
 	Suppress commit summary message.
 
+--submodule|--no-submodule
+    Show/Don't show commit summary for user-cared (i.e. checked out)
+    modified submodules. Summaries for submodules deleted or initial
+    added are not shown. The bool configuration variable
+    'submodule.status' is used to control the default behaviour
+    (don't show by default).
+
 \--::
 	Do not interpret any more arguments as options.
 
@@ -259,6 +266,9 @@ GIT_EDITOR environment variable, the core.editor configuration variable, the
 VISUAL environment variable, or the EDITOR environment variable (in that
 order).
 
+The bool configuration variable 'submodule.status' is also honored to
+enable/disable the submodule summary behaviour (see option --submodule).
+
 HOOKS
 -----
 This command can run `commit-msg`, `pre-commit`, and
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 8fd0fc6..7afe6a0 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -49,6 +49,9 @@ mean the same thing and the latter is kept for backward
 compatibility) and `color.status.<slot>` configuration variables
 to colorize its output.
 
+The bool configuration variable 'submodule.status' is also honored
+to enable/disable the submodule summary behaviour (see option --submodule).
+
 See Also
 --------
 gitlink:gitignore[5]
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..813eb4e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,65 @@ save_index () {
 	cp -p "$THIS_INDEX" "$NEXT_INDEX"
 }
 
+# Show log of modified submodule (index modification since HEAD or $1)
+# $1 is the commit to be compared, default 'HEAD'
+show_module_log () {
+	cwd=$(pwd)
+	cd_to_toplevel
+
+	# get modified modules which have been checked out (i.e. cared by user)
+	modules=$(git diff --cached --name-only $1 |
+	(
+		IFS=''	# handle the module name containing space or tab
+		while read name
+		do
+			git ls-files --stage "$name" | grep '^160000 ' >&/dev/null &&
+			GIT_DIR="$name/.git" git-rev-parse --git-dir >&/dev/null &&
+			echo "$name"
+		done
+	)
+	)
+
+	# TODO: quote module names containing space or tab
+	test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
+	OLDIFS=$IFS
+	IFS=$'\n\r'	# '\r' for mac os
+	for name in $modules
+	do
+		range=$(git diff --cached -- "$name" | sed -n '/^index.*160000$/ p' | awk '{print $2}')
+		indexone=${range#*..}
+		headone=${range%..*}
+		(
+			echo "* $name $headone...$indexone:"
+			headfail=
+			indexfail=
+			GIT_DIR="$name/.git" git-rev-parse $headone >&/dev/null || headfail='t'
+			GIT_DIR="$name/.git" git-rev-parse $indexone >&/dev/null || indexfail='t'
+			case "$headfail,$indexfail" in
+			t,)
+				echo "  Warn: $name doesn't contains commit $headone"
+				;;
+			,t)
+				echo "  Warn: $name doesn't contains commit $indexone"
+				;;
+			t,t)
+				echo "  Warn: $name doesn't contains commits $headone and $indexone"
+				;;
+			*)
+				left=$(GIT_DIR="$name/.git" git log --pretty=format:"  <%s" $indexone..$headone 2>&1)
+				right=$(GIT_DIR="$name/.git" git log --reverse --pretty=format:"  >%s" $headone..$indexone 2>&1) &&
+				test -n "$left" && echo "$left"
+				test -n "$right" && echo "$right"
+				;;
+			esac
+			echo
+		) | sed 's/^/# /'
+	done
+	IFS=$OLDIFS
+
+	cd "$cwd"
+}
+
 run_status () {
 	# If TMP_INDEX is defined, that means we are doing
 	# "--only" partial commit, and that index file is used
@@ -55,10 +114,25 @@ run_status () {
 	else
 		color=--nocolor
 	fi
-	git runstatus ${color} \
-		${verbose:+--verbose} \
-		${amend:+--amend} \
-		${untracked_files:+--untracked}
+	if test -n "$showsubmodule"
+	then
+		git runstatus ${color} \
+			${verbose:+--verbose} \
+			${amend:+--amend} \
+			${untracked_files:+--untracked} |
+		awk -v modulelog="$(show_module_log ${amend:+HEAD^})" '
+		/^# Untracked files:/ {shown=1; if (modulelog) print modulelog}
+		{print}
+		END {
+			if (!shown && modulelog) print modulelog
+		}
+		'
+	else
+		git runstatus ${color} \
+			${verbose:+--verbose} \
+			${amend:+--amend} \
+			${untracked_files:+--untracked}
+	fi
 }
 
 trap '
@@ -90,6 +164,8 @@ force_author=
 only_include_assumed=
 untracked_files=
 templatefile="`git config commit.template`"
+showsubmodule=$(git config --bool submodule.status 2>/dev/null)
+test "$showsubmodule" == "true" || showsubmodule=""
 while test $# != 0
 do
 	case "$1" in
@@ -230,6 +306,12 @@ do
 	--untracked-file|--untracked-files)
 		untracked_files=t
 		;;
+	--su|--sub|--subm|--submo|--submod|--submodu|--submodul|--submodule)
+		showsubmodule=t
+		;;
+	--no-su|--no-sub|--no-subm|--no-submo|--no-submod|--no-submodu|--no-submodul|--no-submodule)
+		showsubmodule=
+		;;
 	--)
 		shift
 		break
-- 
1.5.3.4

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ralf Wildenhues]

Hello,

A couple of portability nits:

* Ping Yin wrote on Mon, Nov 12, 2007 at 03:21:17PM CET:
[...]
> +
> +	# TODO: quote module names containing space or tab
> +	test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"

Typo: s/modifiled/modified/

Then, "echo -e" is not portable (and not used elsewhere in git), but you
can just use this instead:
  test ... && { echo "# ..."; echo "#"; }

Also, it so happens you leave $modules outside quotes which will drop
multiple adjacent white spaces.  Did you mean to use
  echo "# Submodules modified: \"$modules\""
?

> +	OLDIFS=$IFS
> +	IFS=$'\n\r'	# '\r' for mac os

$' is not portable (and not POSIX either).  For example pdksh, OpenBSD
/bin/sh (which are both similar) will add "$" to the list of sepators
here, compare this: 

  $ foo=$'\n'; echo ".$foo."
  .$
  .

And at least some ash/dash versions will not interpret this as a newline
at all:
  .$\n.

You can instead just use a literal newline:
  IFS='
  '

(minus the indentation).  And add a literal carriage return if need be
(is that really needed on Mac OS?), though you may want to enclose that
in another pair of quotes to avoid it being "optimized" away by some
editor.

Cheers,
Ralf

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 12, 2007 10:46 PM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello,
>
> A couple of portability nits:
>
> * Ping Yin wrote on Mon, Nov 12, 2007 at 03:21:17PM CET:
> [...]
> > +
> > +     # TODO: quote module names containing space or tab
> > +     test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
>
> Typo: s/modifiled/modified/
Oops
>
> Then, "echo -e" is not portable (and not used elsewhere in git), but you
> can just use this instead:
>   test ... && { echo "# ..."; echo "#"; }
See
>
> Also, it so happens you leave $modules outside quotes which will drop
> multiple adjacent white spaces.  Did you mean to use
>   echo "# Submodules modified: \"$modules\""
I leave $modules outside quotes to let "\n" change to <space> by auto
word splitting.
It actually eats white spaces in the module names. So any suggestion
to handle this case?
To handles module names with spaces, is it ok to display as follows?

Submodules modified: sm1 "sm name with space"

Any good way to only add quoting for names with spaces?

> You can instead just use a literal newline:
>   IFS='
>   '
> (minus the indentation).  And add a literal carriage return if need be
> (is that really needed on Mac OS?), though you may want to enclose that
> in another pair of quotes to avoid it being "optimized" away by some
> editor.
I just guess '\r' is need for Mac OS because i havn't Mac OS environment.
BTW, how to add a literal carriage return?
>
> Cheers,
> Ralf
>



-- 
Ping Yin

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Brian Gernhardt]

On Nov 12, 2007, at 10:17 AM, Ping Yin wrote:

> I just guess '\r' is need for Mac OS because i havn't Mac OS  
> environment.
> BTW, how to add a literal carriage return?

OS X's command line environment is modeled after BSD and uses the nice  
and sane \n as a line ending.  And since earlier Mac OS versions (that  
did use \r) don't have a command line, I don't see people using git on  
them.

~~ Brian

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Jakub Narebski]

Ping Yin wrote:

> ---
>  Documentation/git-commit.txt |   10 +++++
>  Documentation/git-status.txt |    3 +
>  git-commit.sh                |   90 ++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 99 insertions(+), 4 deletions(-)

Shouldn't you also modify Documentation/config.txt ?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 12, 2007 11:37 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Ping Yin wrote:
>
> > ---
> > Documentation/git-commit.txt | 10 +++++
> > Documentation/git-status.txt | 3 +
> > git-commit.sh | 90 ++++++++++++++++++++++++++++++++++++++++--
> > 3 files changed, 99 insertions(+), 4 deletions(-)
>
> Shouldn't you also modify Documentation/config.txt ?
Oh, I'll supplement later
>
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Ping Yin

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Johannes Sixt]

Ping Yin schrieb:
> git status/commit just treats submodules as ordinary files when reporting status
> changes. However, one may also wonder how submodules change (the commits).
> 
> This commit teaches git status/commit to additionally show commit summary of
> user-cared (i.e. checked out) modified submodules since HEAD (or HEAD^ if
> --amend option is on). For submodules deleted or initially added, commit summary
> are not shown.

In general, I like the idea (as I've already pointed out).

But at this time git-commit is about to be made a builtin, and since your 
implementation contains a lot of non-portable constructs ($'', >&) and a new 
dependency on awk (and, hence, has little chances of being accepted), I 
suggest that you stay tuned, and implement this in the forth-coming 
builtin-commit.c.

> A configuration variable 'submodule.status' is used to turn this summary
> behaviour on or off (default off). Also --submodule and --no-submodule options
> are added.

There is already 'status.color', I suggest the configuration to become 
'status.submoduleSummary'.

-- Hannes

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Jakub Narebski]

Johannes Sixt wrote:

>> A configuration variable 'submodule.status' is used to turn this summary
>> behaviour on or off (default off). Also --submodule and --no-submodule options
>> are added.
> 
> There is already 'status.color', I suggest the configuration to become 
> 'status.submoduleSummary'.

Or status.submodule.summary, although we usually use
section.<variable_sub>.key configuration variables,
e.g. branch.<name>.remote. But we have exception:
color.branch.<slot>

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 13, 2007 12:12 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Johannes Sixt wrote:
>
> >> A configuration variable 'submodule.status' is used to turn this summary
> >> behaviour on or off (default off). Also --submodule and --no-submodule options
> >> are added.
> >
> > There is already 'status.color', I suggest the configuration to become
> > 'status.submoduleSummary'.
>
> Or status.submodule.summary, although we usually use
> section.<variable_sub>.key configuration variables,
> e.g. branch.<name>.remote. But we have exception:
> color.branch.<slot>

maybe submodule.status.summary better?
later new variables can be added easily such as
submodule.status.recursive, submodule.diff, submodule.log
>
> --
>
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Ping Yin

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Johannes Sixt wrote:

> Ping Yin schrieb:
> > git status/commit just treats submodules as ordinary files when 
> > reporting status changes. However, one may also wonder how submodules 
> > change (the commits).
> > 
> > This commit teaches git status/commit to additionally show commit 
> > summary of user-cared (i.e. checked out) modified submodules since 
> > HEAD (or HEAD^ if --amend option is on). For submodules deleted or 
> > initially added, commit summary are not shown.
> 
> In general, I like the idea (as I've already pointed out).
> 
> But at this time git-commit is about to be made a builtin, and since 
> your implementation contains a lot of non-portable constructs ($'', >&) 
> and a new dependency on awk (and, hence, has little chances of being 
> accepted), I suggest that you stay tuned, and implement this in the 
> forth-coming builtin-commit.c.

I agree.

> > A configuration variable 'submodule.status' is used to turn this 
> > summary behaviour on or off (default off). Also --submodule and 
> > --no-submodule options are added.
> 
> There is already 'status.color', I suggest the configuration to become 
> 'status.submoduleSummary'.

You could make this variable even a numeric one.  Saying how many lines 
you want to have maximally (-1 meaning unlimited).

Ciao,
Dscho

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 13, 2007 12:13 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:

> >
> > There is already 'status.color', I suggest the configuration to become
> > 'status.submoduleSummary'.
>
> You could make this variable even a numeric one.  Saying how many lines
> you want to have maximally (-1 meaning unlimited).
Good idea.
However, there is a problem about limiting the lines of commit
summary: if there are 50 backwards and 50 forwards, and summary lines
are limited to 50 lines. How to display? 25 backwards, 25 forwards or
only 50 backwards?
>
> Ciao,
> Dscho
>
>



-- 
Ping Yin

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Johannes Sixt]

Ping Yin schrieb:
> On Nov 13, 2007 12:13 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> 
>>> There is already 'status.color', I suggest the configuration to become
>>> 'status.submoduleSummary'.
>> You could make this variable even a numeric one.  Saying how many lines
>> you want to have maximally (-1 meaning unlimited).
> Good idea.
> However, there is a problem about limiting the lines of commit
> summary: if there are 50 backwards and 50 forwards, and summary lines
> are limited to 50 lines. How to display? 25 backwards, 25 forwards or
> only 50 backwards?

Just use git log --left-right --topo-order, then you can easily insert -$n, 
and git-log will decide where it cuts off the lists.

However, --left-right won't reverse one of the list, like you did.

-- Hannes

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

> But at this time git-commit is about to be made a builtin, and since your
> implementation contains a lot of non-portable constructs ($'', >&) and a new
> dependency on awk (and, hence, has little chances of being accepted), I
> suggest that you stay tuned, and implement this in the forth-coming
> builtin-commit.c.
Implement this in shell scripts is just a piece of cake, but not so
easy in builtin-commit.c. Not to mention that i'm unamiliar with git c
code. $', >& portable problem can be easily corrected. However, awk is
a new dependency? I have seen it in git-mergetool.sh
>
> > A configuration variable 'submodule.status' is used to turn this summary
> > behaviour on or off (default off). Also --submodule and --no-submodule options
> > are added.
>
> There is already 'status.color', I suggest the configuration to become
> 'status.submoduleSummary'.
There is 'status.color', but 'color.status' is prefered as said in the
documentation. So i follows this rule, name the variable submodule.*
just as the ones for git-submodule. I think it's a good idea to put
all submodule related configuration variables in the submodule.*
namespaces.

>
> -- Hannes
>
>



-- 
Ping Yin

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Johannes Sixt]

Ping Yin schrieb:
> On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> 
>> But at this time git-commit is about to be made a builtin, and since your
>> implementation contains a lot of non-portable constructs ($'', >&) and a new
>> dependency on awk (and, hence, has little chances of being accepted), I
>> suggest that you stay tuned, and implement this in the forth-coming
>> builtin-commit.c.
> Implement this in shell scripts is just a piece of cake, but not so
> easy in builtin-commit.c.

I'm with you. But git-commit.sh is a dead horse, no matter how hard you beat it.

BTW, maybe you can keep the log generation in a helper script, 
git-status--submodulesummary, and invoke that from builtin-commit.c. This 
way you get both: integration and ease of implementation.

>>> A configuration variable 'submodule.status' is used to turn this summary
>>> behaviour on or off (default off). Also --submodule and --no-submodule options
>>> are added.
>> There is already 'status.color', I suggest the configuration to become
>> 'status.submoduleSummary'.
> There is 'status.color', but 'color.status' is prefered as said in the
> documentation. So i follows this rule, name the variable submodule.*
> just as the ones for git-submodule. I think it's a good idea to put
> all submodule related configuration variables in the submodule.*
> namespaces.

"I think it's a good idea to put all status related configuration variables 
in the status.* namespace."

But I don't care too deeply. I don't have the big picture about which 
configuration variables namespaces exist and which one to pick in this case.

-- Hannes

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Lars Hjemli]

On Nov 12, 2007 5:45 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Ping Yin schrieb:
> > On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >
> >> But at this time git-commit is about to be made a builtin, and since your
> >> implementation contains a lot of non-portable constructs ($'', >&) and a new
> >> dependency on awk (and, hence, has little chances of being accepted), I
> >> suggest that you stay tuned, and implement this in the forth-coming
> >> builtin-commit.c.
> > Implement this in shell scripts is just a piece of cake, but not so
> > easy in builtin-commit.c.
>
> I'm with you. But git-commit.sh is a dead horse, no matter how hard you beat it.
>
> BTW, maybe you can keep the log generation in a helper script,
> git-status--submodulesummary, and invoke that from builtin-commit.c. This
> way you get both: integration and ease of implementation.

Sorry for repeating myself, but IMVHO this belong in git-submodule.sh:
It can be useful as a standalone command, we get all submodule-related
commands isolated in a single place, and builtin-commit.c can of
course exec git-submodule to get the summary.

--
larsh

Re: [PATCH] status&commit: Teach them to show submodule commit summary

[Ping Yin]

On Nov 13, 2007 1:47 AM, Lars Hjemli <hjemli@gmail.com> wrote:
> On Nov 12, 2007 5:45 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Ping Yin schrieb:
> > > On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > >
> > >> But at this time git-commit is about to be made a builtin, and since your
> > >> implementation contains a lot of non-portable constructs ($'', >&) and a new
> > >> dependency on awk (and, hence, has little chances of being accepted), I
> > >> suggest that you stay tuned, and implement this in the forth-coming
> > >> builtin-commit.c.
> > > Implement this in shell scripts is just a piece of cake, but not so
> > > easy in builtin-commit.c.
> >
> > I'm with you. But git-commit.sh is a dead horse, no matter how hard you beat it.
> >
> > BTW, maybe you can keep the log generation in a helper script,
> > git-status--submodulesummary, and invoke that from builtin-commit.c. This
> > way you get both: integration and ease of implementation.
>
> Sorry for repeating myself, but IMVHO this belong in git-submodule.sh:
> It can be useful as a standalone command, we get all submodule-related
> commands isolated in a single place, and builtin-commit.c can of
> course exec git-submodule to get the summary.
>
OK. I'll reconsider it and reimplement it when i have time.



-- 
Ping Yin

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

[Lars Hjemli]

On Nov 10, 2007 8:27 PM, Ping Yin <pkufranky@gmail.com> wrote:
> This commit teaches git status/commit to also show commits of user-cared
> modified submodules since HEAD (or HEAD^ if --amend option is on).

Some nitpicks:
-we'll need a config option to enable/disable this output in git-status
-the feature should probably be implemented in git-submodule.sh

--
larsh

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

[Yin Ping]

On Nov 11, 2007 8:07 AM, Lars Hjemli <hjemli@gmail.com> wrote:
> On Nov 10, 2007 8:27 PM, Ping Yin <pkufranky@gmail.com> wrote:
> > This commit teaches git status/commit to also show commits of user-cared
> > modified submodules since HEAD (or HEAD^ if --amend option is on).
>
> Some nitpicks:
> -we'll need a config option to enable/disable this output in git-status
agree. default off?
> -the feature should probably be implemented in git-submodule.sh
>
I'll want to see the commits of submodules when editing commit msg. So
i implemented
this in git-commit.sh. May be a configuration/option can added to turn
this on or off.

> --
> larsh
>



-- 
Ping Yin

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

[Lars Hjemli]

On Nov 11, 2007 7:24 AM, Yin Ping <pkufranky@gmail.com> wrote:
> On Nov 11, 2007 8:07 AM, Lars Hjemli <hjemli@gmail.com> wrote:
> > On Nov 10, 2007 8:27 PM, Ping Yin <pkufranky@gmail.com> wrote:
> > > This commit teaches git status/commit to also show commits of user-cared
> > > modified submodules since HEAD (or HEAD^ if --amend option is on).
> >
> > Some nitpicks:
> > -we'll need a config option to enable/disable this output in git-status
> agree. default off?

That would be nice.

> > -the feature should probably be implemented in git-submodule.sh
> >
> I'll want to see the commits of submodules when editing commit msg.

If git-commit.sh uses git-submodule.sh to get this information, the
feature is still available in git-submodule even if it's disabled for
git-status.

--
larsh