threads / discuss / 38347

How to prevent empty git commit --amend

Subject: How to prevent empty git commit --amend

## tl;dr

30 messages between Jan 13, 2015 and Mar 5, 2015.

replies: 29people: 5as markdown or json

Ivo Anjo· Jan 13, 2015, 08:56 UTC · lore
Hello,

I sometimes get a bit distracted when making amends. Once or twice per week I do a commit, then realize I added something I shouldn't, or forgot to add a line here or there, and then I do a git commit --amend to fix it.

The thing is, a lot of times I forget to stage the modifications I did. And here is my issue: *git commit* refuses to work when there's nothing to commit, but *git commit --amend* happily pops up the editor and says you have committed something when you did not add/change anything.

Is there a way to prevent a *git commit --amend** with nothing to commit from working? If not, I would like to suggest that this feature would be very helpful :)

Thanks for your time! Ivo Anjo

Daniel Knittl-Frank· Jan 13, 2015, 08:59 UTC · re: Ivo Anjo · lore

Re: How to prevent empty git commit --amend

On Tue, Jan 13, 2015 at 9:56 AM, Ivo Anjo <ivo.anjo@ist.utl.pt> wrote:
Show 16 quoted lines
> Hello,
>
> I sometimes get a bit distracted when making amends. Once or twice per
> week I do a commit, then realize I added something I shouldn't, or
> forgot to add a line here or there, and then I do a git commit --amend
> to fix it.
>
> The thing is, a lot of times I forget to stage the modifications I did.
> And here is my issue: *git commit* refuses to work when there's
> nothing to commit, but *git commit --amend* happily pops up the editor
> and says you have committed something when you did not add/change
> anything.
>
> Is there a way to prevent a *git commit --amend** with nothing to
> commit from working?
> If not, I would like to suggest that this feature would be very helpful :)
Hi Ivo,

simply delete all text from the commit editor and exit/save the empty file. This will abort the commit.

The same logic applies to git rebase --interactive: deleting everything will do nothing.

Regards, Daniel

-- 
typed with http://neo-layout.org
Ivo Anjo· Jan 13, 2015, 10:22 UTC · re: Daniel Knittl-Frank · lore

Re: How to prevent empty git commit --amend

Hello Daniel,
Thanks for your answer!

My issue is not with cancelling the amend commit, is that because the amend commit already lists changes to the files I am working on (those changes that already went in the commit I was ammending), I don't realize that I forgot to add what I changed. For instance:

$ echo "Hello" >> readme.txt $ git add readme.txt $ git commit -m "Add readme"

$ echo "World" >> readme.txt $ git commit --amend

now if I just save and close the editor git will say it committed successfully (which it did), but in reality nothing at all happened.

Of course I can check the status or some other things before/after the amend commit, but since end up doing this error sometimes I was hoping I could set up git to stop me from doing it.

Ivo Anjo

On Tue, Jan 13, 2015 at 8:59 AM, Daniel Knittl-Frank <knittl89@googlemail.com> wrote:

Show 32 quoted lines
>
> On Tue, Jan 13, 2015 at 9:56 AM, Ivo Anjo <ivo.anjo@ist.utl.pt> wrote:
> > Hello,
> >
> > I sometimes get a bit distracted when making amends. Once or twice per
> > week I do a commit, then realize I added something I shouldn't, or
> > forgot to add a line here or there, and then I do a git commit --amend
> > to fix it.
> >
> > The thing is, a lot of times I forget to stage the modifications I did.
> > And here is my issue: *git commit* refuses to work when there's
> > nothing to commit, but *git commit --amend* happily pops up the editor
> > and says you have committed something when you did not add/change
> > anything.
> >
> > Is there a way to prevent a *git commit --amend** with nothing to
> > commit from working?
> > If not, I would like to suggest that this feature would be very helpful :)
>
> Hi Ivo,
>
> simply delete all text from the commit editor and exit/save the empty
> file. This will abort the commit.
>
> The same logic applies to git rebase --interactive: deleting
> everything will do nothing.
>
> Regards,
> Daniel
>
> --
> typed with http://neo-layout.org
Michael J Gruber· Jan 13, 2015, 11:20 UTC · re: Ivo Anjo · lore

Re: How to prevent empty git commit --amend

Ivo Anjo schrieb am 13.01.2015 um 11:22:
Show 22 quoted lines
> Hello Daniel,
> 
> Thanks for your answer!
> 
> My issue is not with cancelling the amend commit, is that because the
> amend commit already lists changes to the files I am working on (those
> changes that already went in the commit I was ammending), I don't
> realize that I forgot to add what I changed. For instance:
> 
> $ echo "Hello" >> readme.txt
> $ git add readme.txt
> $ git commit -m "Add readme"
> 
> $ echo "World" >> readme.txt
> $ git commit --amend
> 
> now if I just save and close the editor git will say it committed
> successfully (which it did), but in reality nothing at all happened.
> 
> Of course I can check the status or some other things before/after the
> amend commit, but since end up doing this error sometimes I was hoping
> I could set up git to stop me from doing it.

"git commit --amend" is (also) the way to edit the last commit message, and for that you need to be able to do an "empty" amend.

In your example above, git will also tell you that you have unstaged changes to readme.txt.

If that isn't enough, you can use "-v" to display the diff in the editor (and remove it).

Michael
Matthieu Moy· Jan 14, 2015, 10:00 UTC · re: Ivo Anjo · lore

Re: How to prevent empty git commit --amend

Ivo Anjo <ivo.anjo@ist.utl.pt> writes:
> Is there a way to prevent a *git commit --amend** with nothing to
> commit from working?
> If not, I would like to suggest that this feature would be very helpful :)
I don't know any way to let Git do the check for you, but 
git diff --staged --quiet || git commit --amend
should do it. You can alias it like
[alias]
	amend = !git diff --staged --quiet || git commit --amend
and then use "git amend".
-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Ivo Anjo· Jan 14, 2015, 12:15 UTC · re: Matthieu Moy · lore

Re: How to prevent empty git commit --amend

Hello,

On Wed, Jan 14, 2015 at 10:00 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 10 quoted lines
> I don't know any way to let Git do the check for you, but
>
> git diff --staged --quiet || git commit --amend
>
> should do it. You can alias it like
>
> [alias]
>         amend = !git diff --staged --quiet || git commit --amend
>
> and then use "git amend".
Genius! This is exactly what I wanted, thanks!
Ivo Anjo
Matthieu Moy· Jan 14, 2015, 12:45 UTC · re: Ivo Anjo · lore

Re: How to prevent empty git commit --amend

Ivo Anjo <ivo.anjo@ist.utl.pt> writes:
Show 10 quoted lines
> Hello,
>
> On Wed, Jan 14, 2015 at 10:00 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> [alias]
>>         amend = !git diff --staged --quiet || git commit --amend
>>
>> and then use "git amend".
>
> Genius! This is exactly what I wanted, thanks!

You probably want to tweak the alias by adding a && echo "Nothing to commit, sorry" (or an if/then/fi) after git diff to get the appropriate error message though.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano· Jan 14, 2015, 17:27 UTC · re: Matthieu Moy · lore

Re: How to prevent empty git commit --amend

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 16 quoted lines
> Ivo Anjo <ivo.anjo@ist.utl.pt> writes:
>
>> Is there a way to prevent a *git commit --amend** with nothing to
>> commit from working?
>> If not, I would like to suggest that this feature would be very helpful :)
>
> I don't know any way to let Git do the check for you, but 
>
> git diff --staged --quiet || git commit --amend
>
> should do it. You can alias it like
>
> [alias]
> 	amend = !git diff --staged --quiet || git commit --amend
>
> and then use "git amend".
That would not let you say "git amend Makefile", no?
	!sh -c 'git diff --cached --quiet "$@" || git commit --amend "$@"' -
or something, perhaps?
Junio C Hamano· Jan 14, 2015, 17:36 UTC · re: Junio C Hamano · lore

Re: How to prevent empty git commit --amend

Junio C Hamano <gitster@pobox.com> writes:
Show 24 quoted lines
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Ivo Anjo <ivo.anjo@ist.utl.pt> writes:
>>
>>> Is there a way to prevent a *git commit --amend** with nothing to
>>> commit from working?
>>> If not, I would like to suggest that this feature would be very helpful :)
>>
>> I don't know any way to let Git do the check for you, but 
>>
>> git diff --staged --quiet || git commit --amend
>>
>> should do it. You can alias it like
>>
>> [alias]
>> 	amend = !git diff --staged --quiet || git commit --amend
>>
>> and then use "git amend".
>
> That would not let you say "git amend Makefile", no?
>
> 	!sh -c 'git diff --cached --quiet "$@" || git commit --amend "$@"' -
>
> or something, perhaps?
Heh, not that but something like that ;-).
 * If we have pathspec, we would want to see if the HEAD and the
   working tree differ at the given paths;
 * Otherwise we would want to see if the HEAD and the index differ.
So it would be more like this, I guess.
	case "$#" in
        0)	git diff --quiet --cached ;;
        *)	git diff --quiet HEAD -- "$@" ;;
	esac || git commit --amend ${1+--} "$@"
Michael J Gruber· Jan 15, 2015, 16:08 UTC · re: Junio C Hamano · lore

[RFC/PATCH] commit/status: show the index-worktree with -v -v

git commit and git status in long format show the diff between HEAD and the index when given -v. This allows previewing a commit to be made.

They also list tracked files with unstaged changes, but without a diff.

Introduce '-v -v' which shows the diff between the index and the worktree in addition to HEAD index diff. This allows to review unstaged changes which might be missing from the commit.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Also, the git status man page does not mention -v at all, and the doc
for git status (long format) and the status parts of the git commit
man page should really be the same.
In any case, this may have helped the OP with his amend oversight.
 Documentation/git-commit.txt | 4 ++++
 wt-status.c                  | 8 ++++++++
 2 files changed, 12 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
 	would be committed at the bottom of the commit message
 	template.  Note that this diff output doesn't have its
 	lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
 
 -q::
 --quiet::
diff --git a/wt-status.c b/wt-status.c
index b54eac5..75674c2 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
 		wt_status_add_cut_line(s->fp);
 	}
 	run_diff_index(&rev, 1);
+	if (s->verbose > 1) {
+		setup_work_tree();
+		if (read_cache_preload(&rev.diffopt.pathspec) < 0)
+			perror("read_cache_preload");
+		rev.diffopt.a_prefix = 0; /* allow run_diff_files */
+		rev.diffopt.b_prefix = 0; /* to reset the prefixes */
+		run_diff_files(&rev, 0);
+	}
 }
 
 static void wt_status_print_tracking(struct wt_status *s)
-- 
2.3.0.rc0.202.g6f441c7
Junio C Hamano· Jan 15, 2015, 20:11 UTC · re: Michael J Gruber · lore

Re: [RFC/PATCH] commit/status: show the index-worktree with -v -v

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 16 quoted lines
> git commit and git status in long format show the diff between HEAD
> and the index when given -v. This allows previewing a commit to be made.
>
> They also list tracked files with unstaged changes, but without a diff.
>
> Introduce '-v -v' which shows the diff between the index and the
> worktree in addition to HEAD index diff. This allows to review unstaged
> changes which might be missing from the commit.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> Also, the git status man page does not mention -v at all, and the doc
> for git status (long format) and the status parts of the git commit
> man page should really be the same.
>
> In any case, this may have helped the OP with his amend oversight.

Hmm, does this show what change relative to HEAD is committed fully and then after that show what change relative to the index being commited remains in the working tree at the end?

I do not think that output order is very helpful. Two diffs to the same file next to each other may make it easier to notice, though. That is, not like this:

	diff --git a/A b/A
        ...
        diff --git a/B b/B
        ...
        diff --git i/A w/A
        ...
but like this:
	diff --git a/A b/A
        ...
        diff --git i/A w/A
        ...
        diff --git a/B b/B
        ...
or it may want to even be like this:
	diff --git a/A b/A
        ...
        diff --git to-be-committed/A left-out-of-the-commit/A
        ...
        diff --git a/B b/B
        ...
by using a custom, unusual and easy-to-notice prefixes.
Show 31 quoted lines
>  Documentation/git-commit.txt | 4 ++++
>  wt-status.c                  | 8 ++++++++
>  2 files changed, 12 insertions(+)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 1e74b75..f14d2ec 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
>  	would be committed at the bottom of the commit message
>  	template.  Note that this diff output doesn't have its
>  	lines prefixed with '#'.
> ++
> +If specified twice, show in addition the unified diff between
> +what would be committed and the worktree files, i.e. the unstaged
> +changes to tracked files.
>  
>  -q::
>  --quiet::
> diff --git a/wt-status.c b/wt-status.c
> index b54eac5..75674c2 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
>  		wt_status_add_cut_line(s->fp);
>  	}
>  	run_diff_index(&rev, 1);
> +	if (s->verbose > 1) {
> +		setup_work_tree();
> +		if (read_cache_preload(&rev.diffopt.pathspec) < 0)
> +			perror("read_cache_preload");

Hmm, as we have run diff-index already, we must have had the index loaded, no? What is going on here?

> +		rev.diffopt.a_prefix = 0; /* allow run_diff_files */
> +		rev.diffopt.b_prefix = 0; /* to reset the prefixes */

This is not just "allow to reset the prefixes", but forces the use of mnemonic prefixes to make sure they look different from the normal "diff --cached" output that shows what is going to be committed. If we were to do this, for consistency, we may want to use the mnemonic prefix for the "to be commited" part, no?

Show 5 quoted lines
> +		run_diff_files(&rev, 0);
> +	}
>  }
>  
>  static void wt_status_print_tracking(struct wt_status *s)
Junio C Hamano· Jan 15, 2015, 20:38 UTC · re: Junio C Hamano · lore

Re: [RFC/PATCH] commit/status: show the index-worktree with -v -v

Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> I do not think that output order is very helpful.  Two diffs to the
> same file next to each other may make it easier to notice, though.
> ...
> or it may want to even be like this:
>
> 	  diff --git a/A b/A
>         ...
>         diff --git to-be-committed/A left-out-of-the-commit/A
>         ...
>         diff --git a/B b/B
>         ...
>
> by using a custom, unusual and easy-to-notice prefixes.

FWIW, with such a loud custom prefixes, I think it is OK to have all the changes to be committed first and then everything that is left out at the end.

Michael J Gruber· Jan 16, 2015, 08:13 UTC · re: Junio C Hamano · lore

Re: [RFC/PATCH] commit/status: show the index-worktree with -v -v

Junio C Hamano schrieb am 15.01.2015 um 21:11:
Show 88 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> git commit and git status in long format show the diff between HEAD
>> and the index when given -v. This allows previewing a commit to be made.
>>
>> They also list tracked files with unstaged changes, but without a diff.
>>
>> Introduce '-v -v' which shows the diff between the index and the
>> worktree in addition to HEAD index diff. This allows to review unstaged
>> changes which might be missing from the commit.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> Also, the git status man page does not mention -v at all, and the doc
>> for git status (long format) and the status parts of the git commit
>> man page should really be the same.
>>
>> In any case, this may have helped the OP with his amend oversight.
> 
> Hmm, does this show what change relative to HEAD is committed fully
> and then after that show what change relative to the index being
> commited remains in the working tree at the end?  
> 
> I do not think that output order is very helpful.  Two diffs to the
> same file next to each other may make it easier to notice, though.
> That is, not like this:
> 
> 	diff --git a/A b/A
>         ...
>         diff --git a/B b/B
>         ...
>         diff --git i/A w/A
>         ...
> 
> but like this:
> 
> 	diff --git a/A b/A
>         ...
>         diff --git i/A w/A
>         ...
>         diff --git a/B b/B
>         ...
> 
> or it may want to even be like this:
> 
> 	diff --git a/A b/A
>         ...
>         diff --git to-be-committed/A left-out-of-the-commit/A
>         ...
>         diff --git a/B b/B
>         ...
> 
> by using a custom, unusual and easy-to-notice prefixes.
> 
>>  Documentation/git-commit.txt | 4 ++++
>>  wt-status.c                  | 8 ++++++++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
>> index 1e74b75..f14d2ec 100644
>> --- a/Documentation/git-commit.txt
>> +++ b/Documentation/git-commit.txt
>> @@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
>>  	would be committed at the bottom of the commit message
>>  	template.  Note that this diff output doesn't have its
>>  	lines prefixed with '#'.
>> ++
>> +If specified twice, show in addition the unified diff between
>> +what would be committed and the worktree files, i.e. the unstaged
>> +changes to tracked files.
>>  
>>  -q::
>>  --quiet::
>> diff --git a/wt-status.c b/wt-status.c
>> index b54eac5..75674c2 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
>>  		wt_status_add_cut_line(s->fp);
>>  	}
>>  	run_diff_index(&rev, 1);
>> +	if (s->verbose > 1) {
>> +		setup_work_tree();
>> +		if (read_cache_preload(&rev.diffopt.pathspec) < 0)
>> +			perror("read_cache_preload");
> 
> Hmm, as we have run diff-index already, we must have had the index
> loaded, no?  What is going on here?

It was late and simply calling run_diff_files() didn't work (because of the missing setup_work_tree()), so I added the lines from our diff.c and overlooked that read_cache_preload() must have happened somewhere already.

Show 8 quoted lines
>> +		rev.diffopt.a_prefix = 0; /* allow run_diff_files */
>> +		rev.diffopt.b_prefix = 0; /* to reset the prefixes */
> 
> This is not just "allow to reset the prefixes", but forces the use
> of mnemonic prefixes to make sure they look different from the
> normal "diff --cached" output that shows what is going to be
> committed.  If we were to do this, for consistency, we may want to
> use the mnemonic prefix for the "to be commited" part, no?
I guess here I got blinded by me default config which does that.
Show 6 quoted lines
> 
>> +		run_diff_files(&rev, 0);
>> +	}
>>  }
>>  
>>  static void wt_status_print_tracking(struct wt_status *s)

I really like your suggestion to use more verbose prefixes here for both cases. I guess we can do without additional subheadings for the diffs then.

As for the helpfulness, the intention was to show the diff for the two categories of changes which "git status" lists without diff already:

- changes to be committed (+index -HEAD) aka "git diff --cached"
- changes present in worktree not to be committed (+worktree -index) aka
"git diff"

The paths which would appear in the diff "+worktree -HEAD" are not mentioned in "git status" per se (as a category with subheading), although they fall into at least 1 of the 2 categories, of course.

Michael
Michael J Gruber· Mar 3, 2015, 14:16 UTC · re: Michael J Gruber · lore

[PATCHv2 0/2] More diffs for commit/status

Trying to clean up my old RFCs, so here's a mini-series that
1) adds a test for "status -v" (the diff between HEAD and index) and
2) implements "status -v -v" (additional diff between index and worktree).

The idea is that in a case where "commit -v" would list fils with unstaged changes one would get the diff for these changes with '-v -v' easily.

2/2 also sets the diff prefixes (a/,b/ etc.) for both diffs in the '-v -v' case to a really verbose version to avoid any confusion between the two types of diffs. We may want to do that for '-v' already, although that would be a change in behavior.

The wording for the new prefixes is chosen after the status hints, although they are not localised.

Michael J Gruber (2):
  t7508: test git status -v
  commit/status: show the index-worktree diff with -v -v
 Documentation/git-commit.txt |  4 ++++
 t/t7508-status.sh            | 49 ++++++++++++++++++++++++++++++++++++++++++++
 wt-status.c                  | 10 +++++++++
 3 files changed, 63 insertions(+)
-- 
2.3.1.303.g5174db1
Michael J Gruber· Mar 3, 2015, 14:16 UTC · re: Michael J Gruber · lore

[PATCHv2 1/2] t7508: test git status -v

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t7508-status.sh | 6 ++++++
 1 file changed, 6 insertions(+)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8ed5788..4989e98 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
 	test_i18ncmp expect output
 '
 
+test_expect_success 'status -v' '
+	git diff --cached >>expect &&
+	git status -v >output &&
+	test_cmp expect output
+'
+
 test_expect_success 'setup fake editor' '
 	cat >.git/editor <<-\EOF &&
 	#! /bin/sh
-- 
2.3.1.303.g5174db1
Junio C Hamano· Mar 3, 2015, 21:20 UTC · re: Michael J Gruber · lore

Re: [PATCHv2 1/2] t7508: test git status -v

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 15 quoted lines
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>  t/t7508-status.sh | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index 8ed5788..4989e98 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
>  	test_i18ncmp expect output
>  '
>  
> +test_expect_success 'status -v' '
> +	git diff --cached >>expect &&

This makes the test rely on the previous one succeeding. Do we care, or is reproducing what ought to be in 'expect' at this step too expensive?

Show 7 quoted lines
> +	git status -v >output &&
> +	test_cmp expect output
> +'
> +
>  test_expect_success 'setup fake editor' '
>  	cat >.git/editor <<-\EOF &&
>  	#! /bin/sh
Junio C Hamano· Mar 3, 2015, 22:26 UTC · re: Junio C Hamano · lore

Re: [PATCHv2 1/2] t7508: test git status -v

Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>>  t/t7508-status.sh | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
>> index 8ed5788..4989e98 100755
>> --- a/t/t7508-status.sh
>> +++ b/t/t7508-status.sh
>> @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
>>  	test_i18ncmp expect output
>>  '
>>  
>> +test_expect_success 'status -v' '
>> +	git diff --cached >>expect &&
>
> This makes the test rely on the previous one succeeding.  Do we
> care, or is reproducing what ought to be in 'expect' at this step
> too expensive?
Ahh, OK.  The way the existing tests prepare 'expect' is "by hand".

So I think what is wrong with this new test is not that relies on the current contents of 'expect', but that it modifies it (imagine being a merge/patch monkey who has to accept this change while a change from somebody else that wants to add another test that relies on the original 'expect' intact and then have to scratch his or her head when the two topics are merged, wondering why the latter test starts failing).

Perhaps
	( cat expect && git diff --cached ) >expect-with-v &&
        git status -v >actual &&
        test_cmp expect-with-v actual
or something?
Michael J Gruber· Mar 4, 2015, 11:05 UTC · re: Junio C Hamano · lore

Re: [PATCHv2 1/2] t7508: test git status -v

Junio C Hamano venit, vidit, dixit 03.03.2015 23:26:
Show 41 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>>> ---
>>>  t/t7508-status.sh | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
>>> index 8ed5788..4989e98 100755
>>> --- a/t/t7508-status.sh
>>> +++ b/t/t7508-status.sh
>>> @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
>>>  	test_i18ncmp expect output
>>>  '
>>>  
>>> +test_expect_success 'status -v' '
>>> +	git diff --cached >>expect &&
>>
>> This makes the test rely on the previous one succeeding.  Do we
>> care, or is reproducing what ought to be in 'expect' at this step
>> too expensive?
> 
> Ahh, OK.  The way the existing tests prepare 'expect' is "by hand".
> 
> So I think what is wrong with this new test is not that relies on
> the current contents of 'expect', but that it modifies it (imagine
> being a merge/patch monkey who has to accept this change while a
> change from somebody else that wants to add another test that relies
> on the original 'expect' intact and then have to scratch his or her
> head when the two topics are merged, wondering why the latter test
> starts failing).
> 
> Perhaps
> 
> 	( cat expect && git diff --cached ) >expect-with-v &&
>         git status -v >actual &&
>         test_cmp expect-with-v actual
> 
> or something?

That's what I had first, but the new file shows up as untracked file in the status output...

I don't mind setting this one up by hand also, if you prefer.
Michael
Junio C Hamano· Mar 4, 2015, 21:27 UTC · re: Michael J Gruber · lore

Re: [PATCHv2 1/2] t7508: test git status -v

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 20 quoted lines
>> Ahh, OK.  The way the existing tests prepare 'expect' is "by hand".
>> 
>> So I think what is wrong with this new test is not that relies on
>> the current contents of 'expect', but that it modifies it (imagine
>> being a merge/patch monkey who has to accept this change while a
>> change from somebody else that wants to add another test that relies
>> on the original 'expect' intact and then have to scratch his or her
>> head when the two topics are merged, wondering why the latter test
>> starts failing).
>> 
>> Perhaps
>> 
>> 	( cat expect && git diff --cached ) >expect-with-v &&
>>         git status -v >actual &&
>>         test_cmp expect-with-v actual
>> 
>> or something?
>
> That's what I had first, but the new file shows up as untracked file in
> the status output...

If we step back and wonder why it is not a problem for the test to create 'expect' and 'output' that are not untracked, what would we find?

It seems that there are two ways to do this:
 - Spell these out in 'expect' as untracked; or
 - Throw them in .gitignore to be ignored by 'status'.

As some other tests want to see how untracked files appear in the output, I wonder if throwing expect and output that are already used in the test, together with the new "expect-with-v" and friends, to a .gitignore file might not be a better direction to go.

Perhaps such a clean-up effort might begin with something like this patch?

-- >8 -- t7508: .gitignore 'expect' and 'output' files

These files are used to observe the behaviour of the 'status' command and if there weren't any such observer, the expected output from 'status' wouldn't even mention them.

Place them in .gitignore to unclutter the output expected by the tests. An added benefit is that future tests can add such files that are purely for use by the observer, i.e. the tests themselves, by naming them as expect-foo and/or output-bar.

---
 t/t7508-status.sh | 62 +++++--------------------------------------------------
 1 file changed, 5 insertions(+), 57 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8ed5788..9d944a3 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -320,7 +320,11 @@ EOF
 	test_i18ncmp expect output
 '
 
-rm -f .gitignore
+cat >.gitignore <<\EOF
+.gitignore
+expect*
+output*
+EOF
 
 cat >expect <<\EOF
 ## master
@@ -329,8 +333,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -434,8 +436,6 @@ Untracked files:
 	dir2/modified
 	dir2/untracked
 	dir3/
-	expect
-	output
 	untracked
 
 EOF
@@ -456,8 +456,6 @@ A  dir2/added
 ?? dir2/modified
 ?? dir2/untracked
 ?? dir3/
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s -unormal' '
@@ -493,8 +491,6 @@ Untracked files:
 	dir2/untracked
 	dir3/untracked1
 	dir3/untracked2
-	expect
-	output
 	untracked
 
 EOF
@@ -518,8 +514,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s -uall' '
@@ -554,8 +548,6 @@ Untracked files:
 	untracked
 	../dir2/modified
 	../dir2/untracked
-	../expect
-	../output
 	../untracked
 
 EOF
@@ -569,8 +561,6 @@ A  ../dir2/added
 ?? untracked
 ?? ../dir2/modified
 ?? ../dir2/untracked
-?? ../expect
-?? ../output
 ?? ../untracked
 EOF
 test_expect_success 'status -s with relative paths' '
@@ -586,8 +576,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -625,8 +613,6 @@ Untracked files:
 	<BLUE>dir1/untracked<RESET>
 	<BLUE>dir2/modified<RESET>
 	<BLUE>dir2/untracked<RESET>
-	<BLUE>expect<RESET>
-	<BLUE>output<RESET>
 	<BLUE>untracked<RESET>
 
 EOF
@@ -647,8 +633,6 @@ cat >expect <<\EOF
 <BLUE>??<RESET> dir1/untracked
 <BLUE>??<RESET> dir2/modified
 <BLUE>??<RESET> dir2/untracked
-<BLUE>??<RESET> expect
-<BLUE>??<RESET> output
 <BLUE>??<RESET> untracked
 EOF
 
@@ -676,8 +660,6 @@ cat >expect <<\EOF
 <BLUE>??<RESET> dir1/untracked
 <BLUE>??<RESET> dir2/modified
 <BLUE>??<RESET> dir2/untracked
-<BLUE>??<RESET> expect
-<BLUE>??<RESET> output
 <BLUE>??<RESET> untracked
 EOF
 
@@ -694,8 +676,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -755,8 +735,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -772,8 +750,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -798,8 +774,6 @@ Untracked files:
 
 	dir1/untracked
 	dir2/
-	expect
-	output
 	untracked
 
 EOF
@@ -848,8 +822,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -870,8 +842,6 @@ A  sm
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary is disabled by default' '
@@ -913,8 +883,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -940,8 +908,6 @@ A  sm
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary' '
@@ -964,8 +930,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 no changes added to commit (use "git add" and/or "git commit -a")
@@ -983,8 +947,6 @@ cat >expect <<EOF
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary (clean submodule)' '
@@ -1025,8 +987,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1080,8 +1040,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1192,8 +1150,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1254,8 +1210,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1336,8 +1290,6 @@ cat > expect << EOF
 ;	dir1/untracked
 ;	dir2/modified
 ;	dir2/untracked
-;	expect
-;	output
 ;	untracked
 ;
 EOF
@@ -1369,8 +1321,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 no changes added to commit (use "git add" and/or "git commit -a")
@@ -1400,8 +1350,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
Michael J Gruber· Mar 3, 2015, 14:16 UTC · re: Michael J Gruber · lore

[PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v

git commit and git status in long format show the diff between HEAD and the index when given -v. This allows previewing a commit to be made.

They also list tracked files with unstaged changes, but without a diff.

Introduce '-v -v' which shows the diff between the index and the worktree in addition to the HEAD index diff. This allows a review of unstaged changes which might be missing from the commit.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-commit.txt |  4 ++++
 t/t7508-status.sh            | 43 +++++++++++++++++++++++++++++++++++++++++++
 wt-status.c                  | 10 ++++++++++
 3 files changed, 57 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
 	would be committed at the bottom of the commit message
 	template.  Note that this diff output doesn't have its
 	lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
 
 -q::
 --quiet::
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 4989e98..6779195 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -139,6 +139,49 @@ test_expect_success 'status -v' '
 	test_cmp expect output
 '
 
+cat >expect <<\EOF
+On branch master
+Changes to be committed:
+  (use "git reset HEAD <file>..." to unstage)
+
+	new file:   dir2/added
+
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	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
+
+diff --git HEAD=base-commit/dir2/added INDEX=staged-for-commit/dir2/added
+new file mode 100644
+index 0000000..00750ed
+--- /dev/null
++++ INDEX=staged-for-commit/dir2/added
+@@ -0,0 +1 @@
++3
+diff --git INDEX=staged-for-commit/dir1/modified WORKTREE=not-staged-for-commit/dir1/modified
+index e69de29..d00491f 100644
+--- INDEX=staged-for-commit/dir1/modified
++++ WORKTREE=not-staged-for-commit/dir1/modified
+@@ -0,0 +1 @@
++1
+EOF
+
+test_expect_success 'status -v -v' '
+	git status -v -v >output &&
+	test_cmp expect output
+'
+
 test_expect_success 'setup fake editor' '
 	cat >.git/editor <<-\EOF &&
 	#! /bin/sh
diff --git a/wt-status.c b/wt-status.c
index 29666d0..b6e9837 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -873,7 +873,17 @@ static void wt_status_print_verbose(struct wt_status *s)
 		rev.diffopt.use_color = 0;
 		wt_status_add_cut_line(s->fp);
 	}
+	if (s->verbose > 1) {
+		rev.diffopt.a_prefix = "HEAD=base-commit/";
+		rev.diffopt.b_prefix = "INDEX=staged-for-commit/";
+	} /* else use prefix as per user config */
 	run_diff_index(&rev, 1);
+	if (s->verbose > 1) {
+		setup_work_tree();
+		rev.diffopt.a_prefix = "INDEX=staged-for-commit/";
+		rev.diffopt.b_prefix = "WORKTREE=not-staged-for-commit/";
+		run_diff_files(&rev, 0);
+	}
 }
 
 static void wt_status_print_tracking(struct wt_status *s)
-- 
2.3.1.303.g5174db1
Junio C Hamano· Mar 3, 2015, 21:26 UTC · re: Michael J Gruber · lore

Re: [PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v

Michael J Gruber <git@drmicha.warpmail.net> writes:
> +diff --git INDEX=staged-for-commit/dir1/modified WORKTREE=not-staged-for-commit/dir1/modified
> +index e69de29..d00491f 100644
> +--- INDEX=staged-for-commit/dir1/modified
> ++++ WORKTREE=not-staged-for-commit/dir1/modified

This might be OK for a project like Git itself, but I suspect people with long pathnames (like, eh, those in Java land) would not appreciate it.

Wouldn't mnemonic prefix, which the users are already familiar with, be the most suitable tool for this disambiguation? After all that was what it was invented for 8 years ago.

Michael J Gruber· Mar 4, 2015, 11:11 UTC · re: Junio C Hamano · lore

Re: [PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v

Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
Show 14 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> +diff --git INDEX=staged-for-commit/dir1/modified WORKTREE=not-staged-for-commit/dir1/modified
>> +index e69de29..d00491f 100644
>> +--- INDEX=staged-for-commit/dir1/modified
>> ++++ WORKTREE=not-staged-for-commit/dir1/modified
> 
> This might be OK for a project like Git itself, but I suspect people
> with long pathnames (like, eh, those in Java land) would not
> appreciate it.
> 
> Wouldn't mnemonic prefix, which the users are already familiar with,
> be the most suitable tool for this disambiguation?  After all that
> was what it was invented for 8 years ago.
Well...:
Show 10 quoted lines
> or it may want to even be like this:
> 
> 	diff --git a/A b/A
>         ...
>         diff --git to-be-committed/A left-out-of-the-commit/A
>         ...
>         diff --git a/B b/B
>         ...
> 
> by using a custom, unusual and easy-to-notice prefixes.

Your idea was to use these verbous prefixes so that one recognizes the different types of diffs, and so that we don't need to sort them by file.

I'm happy with c/,i/ and i/,w/ and without sorting. Maybe we would need headings between the two diffs then?

HEAD/,INDEX/ resp. INDEX/,WORKTREE/ would be a shorter alternativ that is inline with the short acronyms execept for c/, because COMMIT/ (withiut "base") would be misleading during commit -v, I'm afraid.

Michael
Junio C Hamano· Mar 4, 2015, 21:13 UTC · re: Michael J Gruber · lore

Re: [PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 32 quoted lines
> Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> 
>>> +diff --git INDEX=staged-for-commit/dir1/modified
>>> WORKTREE=not-staged-for-commit/dir1/modified
>>> +index e69de29..d00491f 100644
>>> +--- INDEX=staged-for-commit/dir1/modified
>>> ++++ WORKTREE=not-staged-for-commit/dir1/modified
>> 
>> This might be OK for a project like Git itself, but I suspect people
>> with long pathnames (like, eh, those in Java land) would not
>> appreciate it.
>> 
>> Wouldn't mnemonic prefix, which the users are already familiar with,
>> be the most suitable tool for this disambiguation?  After all that
>> was what it was invented for 8 years ago.
>
> Well...:
>
>> or it may want to even be like this:
>> 
>> 	diff --git a/A b/A
>>         ...
>>         diff --git to-be-committed/A left-out-of-the-commit/A
>>         ...
>>         diff --git a/B b/B
>>         ...
>> 
>> by using a custom, unusual and easy-to-notice prefixes.
>
> Your idea was to use these verbous prefixes so that one recognizes the
> different types of diffs, and so that we don't need to sort them by file.

Yeah, but I can become wiser over time and change my opinion, no ;-)?

As to pairing the diffs by paths so that c/i and i/w diffs for the same path come together, which I mentioned in the older message you quoted, I think what you said in response made sense, i.e. "the intention was to show the diff for the two categories of changes which "git status" lists without diff already". So I'd prefer showing c/i diff and then optionall i/w diff like you did, without mixing them together.

> I'm happy with c/,i/ and i/,w/ and without sorting. Maybe we would need
> headings between the two diffs then?

Yup. The i/w diff is a new thing and a heading before it to explain what it is would be very helpful for the users to understand what they are looking at. A new heading before c/i diff might help but it may be OK without. E.g. something along the following lines

    Changes to be committed:
        modified: foo
    Changes left in the working tree:
        modified: bar
    --------------------------------------------------
    Changes to be committed
    diff --git c/foo i/foo
    ...
    
    --------------------------------------------------
    Changes left in the working tree
    diff --git i/bar w/bsar
    ...
    
Michael J Gruber· Mar 5, 2015, 14:13 UTC · re: Junio C Hamano · lore

[PATCHv3 0/3]More diffs for commit/status

v3 has the following changes:
- new leading patch by Junio to clean up t7508 (slightly modified by myself)
- adjust tests accordingly
- revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line
Open questionis for 3/3:
- Do we need the header to stick out even more? (I don't think so, although
  having the STATUS_HEADER color to be different may help.)
- Do we want the header line also for "status -v"? (I would say yes, but that
  would be a change to current behaviour.)
Junio C Hamano (1):
  t7508: .gitignore 'expect' and 'output' files
Michael J Gruber (2):
  t7508: test git status -v
  commit/status: show the index-worktree diff with -v -v
 Documentation/git-commit.txt |   4 ++
 t/t7508-status.sh            | 102 +++++++++++++++----------------------------
 wt-status.c                  |  16 +++++++
 3 files changed, 55 insertions(+), 67 deletions(-)
-- 
2.3.1.303.g5174db1
Junio C Hamano· Mar 5, 2015, 19:25 UTC · re: Michael J Gruber · lore

Re: [PATCHv3 0/3]More diffs for commit/status

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 8 quoted lines
> v3 has the following changes:
> - new leading patch by Junio to clean up t7508 (slightly modified by myself)
> - adjust tests accordingly
> - revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line
>
> Open questionis for 3/3:
> - Do we need the header to stick out even more? (I don't think so, although
>   having the STATUS_HEADER color to be different may help.)

If we have more than one paths in each category, I would think at least a separator line (I used -{50} in my illustration you are replying to) before the verbal "Changes to be committed" would help.

> - Do we want the header line also for "status -v"? (I would say yes, but that
>   would be a change to current behaviour.)

I would not object to it very strongly, but I do not see a point in changing the behaviour.

And I do not see why a new user would want it anyway. There is no need to differenciate the changes to be committed from the changes left in the working tree when the latter is not even shown.

Junio C Hamano· Mar 5, 2015, 20:15 UTC · re: Junio C Hamano · lore

Re: [PATCHv3 0/3]More diffs for commit/status

Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> - Do we want the header line also for "status -v"? (I would say yes, but that
>>   would be a change to current behaviour.)
>
> I would not object to it very strongly, but I do not see a point in
> changing the behaviour.
>
> And I do not see why a new user would want it anyway.  There is no
> need to differenciate the changes to be committed from the changes
> left in the working tree when the latter is not even shown.
Extending this line of thought further.

If I am reading your patch 3/3 right, "status -v -v" shows the header when there are patches to be shown for the category. I am not sure if that is the most helpful way for the users, when either c/i xor i/w diffs is missing.

There are four cases, obviously ;-)
1. When there are changes to be committed:
 a) When there is no change left in the working tree, the proposed
    output would be the same as the more familiar "status -v"
    output.  Showing changes to be committed header would of course
    help.
    I wondered if the proposed behaviour hurts the user by hiding
    the header for changes to be left out, though.  By seeing that
    the second header alone and no diff, the user will be assured
    that there is no changes left in the working tree, forgotten to
    be added.  But this point is minor.  As the users get used to
    the behaviour of "-v -v", they will learn to read the emptyness
    and find its proper meaning that there is no change left out.
    So I think the proposed behaviour would be OK in this case.  In
    fact, not showing the second header when there is no change left
    in the working tree will help potential issues with case 2-b).
 b) When there is change left in the working tree, the proposed
    output is fine.  Two headers are shown to indicate what the
    following diff is about and cleanly shows where the boundary of
    the two classes are (especially if you resurrect the -{50}
    separator line I suggested, at least for the second header).
2. When there is no change to be committed:
 a) When there is no change left in the working tree, the proposed
    output is fine.  There is no output (no header, no diff), and
    the user immediately knows that the working tree and the index
    are clean.
 b) When there are changes left in the working tree, the user sees
    one header followed by a diff in the proposed output.  Visually,
    the single line heading (even with the separateor line) may be
    so small in the context of the whole output, and the user needs
    to READ it to notice that the diff being shown are not what is
    going to be committed.  In other words, it is too similar to the
    proposed output in case 1-a).
    If we show the "to be committed" header followed by no diff, and
    then the second header followed by diff, it would be crystial
    clear to the user, because it looks unusual, that what is shown
    is different from case 1-a).  This would especially be true if
    you resurrected -{50} separator line after the heading.
So, my recommendation for "status -v -v" would be:
    if (there are changes to be committed, or
	there are changes left in the working tree) {
	show "to be committed" with -{50};
        show c/i diff;
    }
    if (there are changes left in the working tree) {
	show "left in the working tree" with -{50};
        show i/w diff;
    }
Junio C Hamano· Mar 5, 2015, 20:27 UTC · re: Junio C Hamano · lore

Re: [PATCHv3 0/3]More diffs for commit/status

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> Extending this line of thought further.
> 
> If I am reading your patch 3/3 right, "status -v -v" shows the
> header when there are patches to be shown for the category.  I am
> not sure if that is the most helpful way for the users, when either
> c/i xor i/w diffs is missing.
> ...
> So, my recommendation for "status -v -v" would be:

Taking the conclusion part of what I said back. I think the exact same reasoning will lead to a much simpler and more concise output by (1) using exactly the same logic you have in 3/3 to decide when to show or not show the headers and (2) adding the ^-{50}$ separator only before the second header that is shown before the changes left in the working tree.

Then, 1-a) will show the same output as "status -v", 1-b) will start as the same as "status -v", followed by a visually significant separator followed by diff, 2-a) will be empty, and 2-b) will start with a visually significant and unusual separator line before the diff. That would make 1-a) and 2-b) visually very distinct and reduce the chance of confusion.

The updated outline for "status -v -v" would be:
     if (there are changes to be committed) {
         show "to be committed" header;
         show c/i diff;
     }
     if (there are changes left in the working tree) {
         show "left in the working tree" with -{50} header;
         show i/w diff;
     }
Thanks.
Michael J Gruber· Mar 5, 2015, 14:13 UTC · re: Junio C Hamano · lore

[PATCHv3 1/3] t7508: .gitignore 'expect' and 'output' files

From: Junio C Hamano <gitster@pobox.com>

These files are used to observe the behaviour of the 'status' command and if there weren't any such observer, the expected output from 'status' wouldn't even mention them.

Place them in .gitignore to unclutter the output expected by the tests. An added benefit is that future tests can add such files that are purely for use by the observer, i.e. the tests themselves, by naming them as expect-foo and/or output-bar.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t7508-status.sh | 78 ++++++++++---------------------------------------------
 1 file changed, 13 insertions(+), 65 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8ed5788..514df67 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -66,6 +66,12 @@ strip_comments () {
 	rm "$1" && mv "$1".tmp "$1"
 }
 
+cat >.gitignore <<\EOF
+.gitignore
+expect*
+output*
+EOF
+
 test_expect_success 'status --column' '
 	cat >expect <<\EOF &&
 # On branch master
@@ -83,8 +89,8 @@ test_expect_success 'status --column' '
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
-#	dir1/untracked dir2/untracked output
-#	dir2/modified  expect         untracked
+#	dir1/untracked dir2/untracked
+#	dir2/modified  untracked
 #
 EOF
 	COLUMNS=50 git -c status.displayCommentPrefix=true status --column="column dense" >output &&
@@ -116,8 +122,6 @@ cat >expect <<\EOF
 #	dir1/untracked
 #	dir2/modified
 #	dir2/untracked
-#	expect
-#	output
 #	untracked
 #
 EOF
@@ -167,8 +171,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -186,8 +188,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -320,7 +320,11 @@ EOF
 	test_i18ncmp expect output
 '
 
-rm -f .gitignore
+cat >.gitignore <<\EOF
+.gitignore
+expect*
+output*
+EOF
 
 cat >expect <<\EOF
 ## master
@@ -329,8 +333,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -434,8 +436,6 @@ Untracked files:
 	dir2/modified
 	dir2/untracked
 	dir3/
-	expect
-	output
 	untracked
 
 EOF
@@ -456,8 +456,6 @@ A  dir2/added
 ?? dir2/modified
 ?? dir2/untracked
 ?? dir3/
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s -unormal' '
@@ -493,8 +491,6 @@ Untracked files:
 	dir2/untracked
 	dir3/untracked1
 	dir3/untracked2
-	expect
-	output
 	untracked
 
 EOF
@@ -518,8 +514,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s -uall' '
@@ -554,8 +548,6 @@ Untracked files:
 	untracked
 	../dir2/modified
 	../dir2/untracked
-	../expect
-	../output
 	../untracked
 
 EOF
@@ -569,8 +561,6 @@ A  ../dir2/added
 ?? untracked
 ?? ../dir2/modified
 ?? ../dir2/untracked
-?? ../expect
-?? ../output
 ?? ../untracked
 EOF
 test_expect_success 'status -s with relative paths' '
@@ -586,8 +576,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -625,8 +613,6 @@ Untracked files:
 	<BLUE>dir1/untracked<RESET>
 	<BLUE>dir2/modified<RESET>
 	<BLUE>dir2/untracked<RESET>
-	<BLUE>expect<RESET>
-	<BLUE>output<RESET>
 	<BLUE>untracked<RESET>
 
 EOF
@@ -647,8 +633,6 @@ cat >expect <<\EOF
 <BLUE>??<RESET> dir1/untracked
 <BLUE>??<RESET> dir2/modified
 <BLUE>??<RESET> dir2/untracked
-<BLUE>??<RESET> expect
-<BLUE>??<RESET> output
 <BLUE>??<RESET> untracked
 EOF
 
@@ -676,8 +660,6 @@ cat >expect <<\EOF
 <BLUE>??<RESET> dir1/untracked
 <BLUE>??<RESET> dir2/modified
 <BLUE>??<RESET> dir2/untracked
-<BLUE>??<RESET> expect
-<BLUE>??<RESET> output
 <BLUE>??<RESET> untracked
 EOF
 
@@ -694,8 +676,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -755,8 +735,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -772,8 +750,6 @@ A  dir2/added
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 
@@ -798,8 +774,6 @@ Untracked files:
 
 	dir1/untracked
 	dir2/
-	expect
-	output
 	untracked
 
 EOF
@@ -848,8 +822,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -870,8 +842,6 @@ A  sm
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary is disabled by default' '
@@ -913,8 +883,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -940,8 +908,6 @@ A  sm
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary' '
@@ -964,8 +930,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 no changes added to commit (use "git add" and/or "git commit -a")
@@ -983,8 +947,6 @@ cat >expect <<EOF
 ?? dir1/untracked
 ?? dir2/modified
 ?? dir2/untracked
-?? expect
-?? output
 ?? untracked
 EOF
 test_expect_success 'status -s submodule summary (clean submodule)' '
@@ -1025,8 +987,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1080,8 +1040,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1192,8 +1150,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1254,8 +1210,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
@@ -1336,8 +1290,6 @@ cat > expect << EOF
 ;	dir1/untracked
 ;	dir2/modified
 ;	dir2/untracked
-;	expect
-;	output
 ;	untracked
 ;
 EOF
@@ -1369,8 +1321,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 no changes added to commit (use "git add" and/or "git commit -a")
@@ -1400,8 +1350,6 @@ Untracked files:
 	dir1/untracked
 	dir2/modified
 	dir2/untracked
-	expect
-	output
 	untracked
 
 EOF
-- 
2.3.1.303.g5174db1
Michael J Gruber· Mar 5, 2015, 14:13 UTC · re: Junio C Hamano · lore

[PATCHv3 2/3] t7508: test git status -v

"status -v" had no test. Include one.

This also requires changing the .gitignore subtests, which is a good thing: they include testing a .gitignore pattern now.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t7508-status.sh | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 514df67..e3c9cf9 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -137,6 +137,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
 	test_i18ncmp expect output
 '
 
+test_expect_success 'status -v' '
+	(cat expect && git diff --cached) >expect-with-v &&
+	git status -v >output &&
+	test_i18ncmp expect-with-v output
+'
+
 test_expect_success 'setup fake editor' '
 	cat >.git/editor <<-\EOF &&
 	#! /bin/sh
@@ -201,7 +207,7 @@ test_expect_success 'status -s' '
 test_expect_success 'status with gitignore' '
 	{
 		echo ".gitignore" &&
-		echo "expect" &&
+		echo "expect*" &&
 		echo "output" &&
 		echo "untracked"
 	} >.gitignore &&
@@ -222,6 +228,7 @@ test_expect_success 'status with gitignore' '
 	!! dir1/untracked
 	!! dir2/untracked
 	!! expect
+	!! expect-with-v
 	!! output
 	!! untracked
 	EOF
@@ -253,6 +260,7 @@ Ignored files:
 	dir1/untracked
 	dir2/untracked
 	expect
+	expect-with-v
 	output
 	untracked
 
@@ -264,7 +272,7 @@ EOF
 test_expect_success 'status with gitignore (nothing untracked)' '
 	{
 		echo ".gitignore" &&
-		echo "expect" &&
+		echo "expect*" &&
 		echo "dir2/modified" &&
 		echo "output" &&
 		echo "untracked"
@@ -285,6 +293,7 @@ test_expect_success 'status with gitignore (nothing untracked)' '
 	!! dir2/modified
 	!! dir2/untracked
 	!! expect
+	!! expect-with-v
 	!! output
 	!! untracked
 	EOF
@@ -312,6 +321,7 @@ Ignored files:
 	dir2/modified
 	dir2/untracked
 	expect
+	expect-with-v
 	output
 	untracked
 
-- 
2.3.1.303.g5174db1
Michael J Gruber· Mar 5, 2015, 14:13 UTC · re: Junio C Hamano · lore

[PATCHv3 3/3] commit/status: show the index-worktree diff with -v -v

git commit and git status in long format show the diff between HEAD and the index when given -v. This allows previewing a commit to be made.

They also list tracked files with unstaged changes, but without a diff.

Introduce '-v -v' which shows the diff between the index and the worktree in addition to the HEAD index diff. This allows a review of unstaged changes which might be missing from the commit.

In the case of '-v -v', additonal header lines
Changes to be committed:
and
Changes not staged for commit:

are inserted before the diffs, which are equal to those in the status part.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-commit.txt |  4 ++++
 t/t7508-status.sh            | 10 ++++++++++
 wt-status.c                  | 16 ++++++++++++++++
 3 files changed, 30 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
 	would be committed at the bottom of the commit message
 	template.  Note that this diff output doesn't have its
 	lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
 
 -q::
 --quiet::
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index e3c9cf9..b392376 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -143,6 +143,16 @@ test_expect_success 'status -v' '
 	test_i18ncmp expect-with-v output
 '
 
+test_expect_success 'status -v -v' '
+	(cat expect &&
+	 echo "Changes to be committed:" &&
+	 git -c diff.mnemonicprefix=true diff --cached &&
+	 echo "Changes not staged for commit:" &&
+	 git -c diff.mnemonicprefix=true diff) >expect-with-v &&
+	git status -v -v >output &&
+	test_i18ncmp expect-with-v output
+'
+
 test_expect_success 'setup fake editor' '
 	cat >.git/editor <<-\EOF &&
 	#! /bin/sh
diff --git a/wt-status.c b/wt-status.c
index 29666d0..3cdb356 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -849,6 +849,8 @@ static void wt_status_print_verbose(struct wt_status *s)
 {
 	struct rev_info rev;
 	struct setup_revision_opt opt;
+	int dirty_submodules;
+	const char *c = color(WT_STATUS_HEADER, s);
 
 	init_revisions(&rev, NULL);
 	DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
@@ -873,7 +875,21 @@ static void wt_status_print_verbose(struct wt_status *s)
 		rev.diffopt.use_color = 0;
 		wt_status_add_cut_line(s->fp);
 	}
+	if (s->verbose > 1 && s->commitable) {
+		/* print_updated() printed header */
+		status_printf_ln(s, c, _("Changes to be committed:"));
+		rev.diffopt.a_prefix = "c/";
+		rev.diffopt.b_prefix = "i/";
+	} /* else use prefix as per user config */
 	run_diff_index(&rev, 1);
+	if (s->verbose > 1 &&
+	    wt_status_check_worktree_changes(s, &dirty_submodules)) {
+		status_printf_ln(s, c, _("Changes not staged for commit:"));
+		setup_work_tree();
+		rev.diffopt.a_prefix = "i/";
+		rev.diffopt.b_prefix = "w/";
+		run_diff_files(&rev, 0);
+	}
 }
 
 static void wt_status_print_tracking(struct wt_status *s)
-- 
2.3.1.303.g5174db1

← back to recent threads