IMO, git submodule summary is not so useful for me if it's not
integrated into git-status. In fact i never use "git submodule
summary" directly. git-status with submodule summary support is very
useful to help user figure out what is going on in a more global level
when cooking the commit message.
So i think this series should go along with the submodule summary series.
The v2 series has following commits adding a new commit for documentation
git-submodule summary: --for-status option
builtin-status: submodule summary support
builtin-status: configurable submodule summary size
buitin-status: Add tests for submodule summary
git-status: Mention status.submodulesummary config in the documentation
and diff relative to v1 is (not containing the documetation patch)
@@ -339,8 +339,6 @@ void wt_status_print(struct wt_status *s)}wt_status_print_changed(s);-// must flush s->fp since following call will write to s->fp in a child process-fflush(s->fp);wt_status_print_submodule_summary(s);wt_status_print_untracked(s);
The --for-status option is mainly used by builtin-status/commit.
It adds 'Modified submodules:' line at top and '# ' prefix to all
following lines.
Signed-off-by: Ping Yin <redacted>
---
git-submodule.sh | 17 ++++++++++++++++-
t/t7401-submodule-summary.sh | 13 +++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
Add config variable status.submodulesummary which is passed as
arg for '--summary-limit' of 'git submodule summary' to limit the
submodule summary size.
status.submodulesummary is 0 by default which disables the summary.
Signed-off-by: Ping Yin <redacted>
---
wt-status.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
@@ -12,6 +12,7 @@intwt_status_relative_paths=1;intwt_status_use_color=-1;+intwt_status_submodule_summary=0;staticcharwt_status_colors[][COLOR_MAXLEN]={"",/* WT_STATUS_HEADER: normal */"\033[32m",/* WT_STATUS_UPDATED: green */
@@ -52,6 +52,10 @@ If the config variable `status.relativePaths` is set to false, then all paths shown are relative to the repository root, not to the current directory.+If 'status.submodulesummary' is set to a non zero number, the submodule+summary will be enabled and a summary of commits for modified submodules+will be shown (see --summary-limit option of linkgit:git-submodule[1]).+ See Also -------- linkgit:gitignore[5]
@@ -149,4 +149,138 @@ test_expect_success 'status of partial commit excluding new file in index' 'test_cmpexpectoutput'+test_expect_success"setup status submodule summary"'+test_create_reposm&&+cdsm&&+:>foo&&+gitaddfoo&&+gitcommit-m"Add foo"&&+cd..&&+gitaddsm+'++cat>expect<<EOF+# On branch master+# Changes to be committed:+# (use "git reset HEAD <file>..." to unstage)+#+# new file: dir2/added+# new file: sm+#+# Changed but not updated:+# (use "git add <file>..." to update what will be committed)+#+# modified: dir1/modified+#+# Untracked files:+# (use "git add <file>..." to include in what will be committed)+#+# dir1/untracked+# dir2/modified+# dir2/untracked+# expect+# output+# untracked+EOF+test_expect_success"status submodule summary is disabled by default"'+gitstatus>output&&+gitdiffexpectoutput+'++head=$(cdsm&&gitrev-parse--short=7--verifyHEAD)++cat>expect<<EOF+# On branch master+# Changes to be committed:+# (use "git reset HEAD <file>..." to unstage)+#+# new file: dir2/added+# new file: sm+#+# Changed but not updated:+# (use "git add <file>..." to update what will be committed)+#+# modified: dir1/modified+#+# Modified submodules:+#+# * sm 0000000...$head (1):+# > Add foo+#+# Untracked files:+# (use "git add <file>..." to include in what will be committed)+#+# dir1/untracked+# dir2/modified+# dir2/untracked+# expect+# output+# untracked+EOF+test_expect_success"status submodule summary"'+gitconfigstatus.submodulesummary10&&+gitstatus>output&&+gitdiffexpectoutput+'+++cat>expect<<EOF+# On branch master+# Changed but not updated:+# (use "git add <file>..." to update what will be committed)+#+# modified: dir1/modified+#+# Untracked files:+# (use "git add <file>..." to include in what will be committed)+#+# dir1/untracked+# dir2/modified+# dir2/untracked+# expect+# output+# untracked+nochangesaddedtocommit(use"git add"and/or"git commit -a")+EOF+test_expect_success"status submodule summary (clean submodule)"'+gitcommit-m"commit submodule"&&+gitconfigstatus.submodulesummary10&&+!gitstatus>output&&+gitdiffexpectoutput+'++cat>expect<<EOF+# On branch master+# Changes to be committed:+# (use "git reset HEAD^1 <file>..." to unstage)+#+# new file: dir2/added+# new file: sm+#+# Changed but not updated:+# (use "git add <file>..." to update what will be committed)+#+# modified: dir1/modified+#+# Modified submodules:+#+# * sm 0000000...$head (1):+# > Add foo+#+# Untracked files:+# (use "git add <file>..." to include in what will be committed)+#+# dir1/untracked+# dir2/modified+# dir2/untracked+# expect+# output+# untracked+EOF+test_expect_success"status submodule summary (--amend)"'+gitconfigstatus.submodulesummary10&&+gitstatus--amend>output&&+gitdiffexpectoutput+'+ test_done
From: Johannes Sixt <hidden> Date: 2016-06-15 22:44:23
Ping Yin schrieb:
IMO, git submodule summary is not so useful for me if it's not
integrated into git-status. In fact i never use "git submodule
summary" directly. git-status with submodule summary support is very
useful to help user figure out what is going on in a more global level
when cooking the commit message.
So i think this series should go along with the submodule summary series.
I think so, too. The changes and defaults in wt-status.c are trivial
enough that they don't penalize traditional git-status users.
The v2 series has following commits adding a new commit for documentation
1 git-submodule summary: --for-status option
2 builtin-status: submodule summary support
3 builtin-status: configurable submodule summary size
4 buitin-status: Add tests for submodule summary
5 git-status: Mention status.submodulesummary config in the documentation
I'd actually squash 2, 3, and 5.
You still have the statement before a declaration in 3/5.
+ if (! wt_status_submodule_summary) return;
And here the important part (IMO) is actually that 'return' should go on a
line of its own.
-- Hannes
On Sat, Mar 15, 2008 at 12:22 AM, Johannes Sixt [off-list ref] wrote:
Ping Yin schrieb:
quoted
IMO, git submodule summary is not so useful for me if it's not
> integrated into git-status. In fact i never use "git submodule
> summary" directly. git-status with submodule summary support is very
> useful to help user figure out what is going on in a more global level
> when cooking the commit message.
>
> So i think this series should go along with the submodule summary series.
I think so, too. The changes and defaults in wt-status.c are trivial
enough that they don't penalize traditional git-status users.
> The v2 series has following commits adding a new commit for documentation
>
> 1 git-submodule summary: --for-status option
> 2 builtin-status: submodule summary support
> 3 builtin-status: configurable submodule summary size
> 4 buitin-status: Add tests for submodule summary
> 5 git-status: Mention status.submodulesummary config in the documentation
I'd actually squash 2, 3, and 5.
You still have the statement before a declaration in 3/5.
Sorry i forgot about it.
> + if (! wt_status_submodule_summary) return;
And here the important part (IMO) is actually that 'return' should go on a
line of its own.