Skip to contentSkip to conversation

How to prevent empty git commit --amend

PATCH Superseded Ivo Anjo 5 participants 30 messages Jun 15, 2016 Documentation

v2 of 4 Superseded Latest is v4 →

lore
Share & tools
lore

Ivo Anjo

author
#0 lore raw

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

#1 lore raw
Quoted 13 lines · Ivo Anjo

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.

Quoted 3 lines

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

Signature · 1 line
typed with http://neo-layout.org
author
#2 lore raw

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

Quoted 32 lines · Daniel Knittl-Frank
Quoted 13 lines · Ivo Anjo

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.

Quoted 3 lines

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

#3 lore raw

Ivo Anjo schrieb am 13.01.2015 um 11:22:

Quoted 16 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
Quoted 6 lines

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

#4 lore raw
In reply to Ivo Anjo
Quoted 3 lines · Ivo Anjo

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

Signature · 2 lines
Matthieu Moy
http://www-verimag.imag.fr/~moy/
author
#5 lore raw

Hello,

Quoted 10 lines · Matthieu Moy

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

#6 lore raw
Quoted 10 lines · Ivo Anjo

Hello,

Quoted 4 lines · Matthieu Moy

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

Signature · 2 lines
Matthieu Moy
http://www-verimag.imag.fr/~moy/
#7 lore raw
In reply to Matthieu Moy
Quoted 8 lines · Matthieu Moy
Quoted 3 lines · Ivo Anjo

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

Quoted 8 lines

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?

#8 lore raw
Quoted 17 lines · Junio C Hamano
Quoted 15 lines · Matthieu Moy
Quoted 3 lines · Ivo Anjo

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
Quoted 7 lines
Quoted 1 line

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+--} "$@"
#9 lore raw

[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 <[email protected]>

---
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(+)
Documentation/git-commit.txt +4 -0
index 1e74b75..f14d2ec 100644
@@ -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::
wt-status.c +8 -0
index b54eac5..75674c2 100644
@@ -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)
Signature · 1 line
2.3.0.rc0.202.g6f441c7
#10 lore raw

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

Quoted 9 lines · Michael J Gruber

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.

Quoted 7 lines
Signed-off-by Michael J Gruber <[email protected]>

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

Quoted 24 lines
 Documentation/git-commit.txt | 4 ++++
 wt-status.c                  | 8 ++++++++
 2 files changed, 12 insertions(+)
Documentation/git-commit.txt +4 -0
index 1e74b75..f14d2ec 100644
@@ -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::
wt-status.c +0 -0
index b54eac5..75674c2 100644

wt-status.c static void wt_status_print_verbose(struct wt_status *s) · line 880

Quoted 7 lines
wt-status.c +4 -0
@@ -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?

wt-status.c static void wt_status_print_verbose(struct wt_status *s) · line 882

Quoted 2 lines
wt-status.c +2 -0
+		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?

Quoted 5 lines
wt-status.c +2 -0
+		run_diff_files(&rev, 0);
+	}
 }
 
 static void wt_status_print_tracking(struct wt_status *s)
#11 lore raw

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

Quoted 5 lines · Junio C Hamano

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:

Quoted 8 lines
	  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.

#12 lore raw

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

In reply to Junio C Hamano

Junio C Hamano schrieb am 15.01.2015 um 21:11:

Quoted 80 lines
Quoted 9 lines · Michael J Gruber

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.

Quoted 7 lines
Signed-off-by Michael J Gruber <[email protected]>

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

Quoted 26 lines
 Documentation/git-commit.txt | 4 ++++
 wt-status.c                  | 8 ++++++++
 2 files changed, 12 insertions(+)
Documentation/git-commit.txt +4 -0
index 1e74b75..f14d2ec 100644
@@ -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::
wt-status.c +0 -0
index b54eac5..75674c2 100644
@@ -874,6 +874,14 @@ static void wt_status_print_verbose(struct wt_status *s)
 		wt_status_add_cut_line(s->fp);
 	}
Quoted 8 lines

wt-status.c static void wt_status_print_verbose(struct wt_status *s) · line 880

Quoted 5 lines
wt-status.c +4 -0
 	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.

Quoted 8 lines

wt-status.c static void wt_status_print_verbose(struct wt_status *s) · line 882

Quoted 2 lines
wt-status.c +2 -0
+		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.

Quoted 6 lines

wt-status.c static void wt_status_print_verbose(struct wt_status *s) · line 887

Quoted 6 lines
wt-status.c +2 -0
+		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

#13 lore raw

PATCH v2 1/2 t7508: test git status -v

Signed-off-by Michael J Gruber <[email protected]>
---
 t/t7508-status.sh | 6 ++++++
 1 file changed, 6 insertions(+)
t/t7508-status.sh +6 -0
index 8ed5788..4989e98 100755
@@ -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
Signature · 1 line
2.3.1.303.g5174db1
#14 lore raw

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

Quoted 10 lines · Michael J Gruber
Signed-off-by Michael J Gruber <[email protected]>
---
 t/t7508-status.sh | 6 ++++++
 1 file changed, 6 insertions(+)
t/t7508-status.sh +0 -0
index 8ed5788..4989e98 100755

t/t7508-status.sh test_expect_success 'status with status.displayCommentPrefix=false' ' · line 137

Quoted 5 lines
t/t7508-status.sh +2 -0
@@ -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?

Quoted 7 lines
t/t7508-status.sh +4 -0
+	git status -v >output &&
+	test_cmp expect output
+'
+
 test_expect_success 'setup fake editor' '
 	cat >.git/editor <<-\EOF &&
 	#! /bin/sh
#15 lore raw

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

Quoted 15 lines · Junio C Hamano
Quoted 13 lines · Michael J Gruber
Signed-off-by Michael J Gruber <[email protected]>
---
 t/t7508-status.sh | 6 ++++++
 1 file changed, 6 insertions(+)
t/t7508-status.sh +0 -0
index 8ed5788..4989e98 100755
@@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
 	test_i18ncmp expect output
 '
Quoted 6 lines

t/t7508-status.sh test_expect_success 'status with status.displayCommentPrefix=false' ' · line 137

Quoted 2 lines
t/t7508-status.sh +2 -0
+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?

#16 lore raw

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

Junio C Hamano venit, vidit, dixit 03.03.2015 23:26:

Quoted 34 lines
Quoted 15 lines · Junio C Hamano
Quoted 13 lines · Michael J Gruber
Signed-off-by Michael J Gruber <[email protected]>
---
 t/t7508-status.sh | 6 ++++++
 1 file changed, 6 insertions(+)
t/t7508-status.sh +0 -0
index 8ed5788..4989e98 100755
@@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' '
 	test_i18ncmp expect output
 '
Quoted 6 lines

t/t7508-status.sh test_expect_success 'status with status.displayCommentPrefix=false' ' · line 137

Quoted 2 lines
t/t7508-status.sh +2 -0
+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).

Quoted 7 lines

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

#17 lore raw

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

Quoted 12 lines · Michael J Gruber
Quoted 12 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

Quoted 8 lines
Quoted 5 lines
	( 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(-)
t/t7508-status.sh +5 -57
index 8ed5788..9d944a3 100755
@@ -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
#18 lore raw

PATCH v2 2/2 commit/status: show the index-worktree diff with -v -v

In reply to Michael J Gruber

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 <[email protected]>
---
 Documentation/git-commit.txt |  4 ++++
 t/t7508-status.sh            | 43 +++++++++++++++++++++++++++++++++++++++++++
 wt-status.c                  | 10 ++++++++++
 3 files changed, 57 insertions(+)
Documentation/git-commit.txt +4 -0
index 1e74b75..f14d2ec 100644
@@ -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::
t/t7508-status.sh +43 -0

49 lines not on this page · raw message

wt-status.c +10 -0
index 29666d0..b6e9837 100644
@@ -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)
Signature · 1 line
2.3.1.303.g5174db1
#19 lore raw

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

t/t7508-status.sh test_expect_success 'status -v' ' · line 175

Quoted 4 lines · Michael J Gruber
t/t7508-status.sh +4 -0
+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.

#20 lore raw

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:

Quoted 11 lines

t/t7508-status.sh test_expect_success 'status -v' ' · line 175

Quoted 4 lines · Michael J Gruber
t/t7508-status.sh +4 -0
+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.

Quoted 3 lines

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

Quoted 10 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

#21 lore raw

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

Quoted 28 lines · Michael J Gruber

Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:

Quoted 12 lines
Quoted 5 lines · Michael J Gruber

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

Quoted 3 lines

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

Quoted 9 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
        ...
Quoted 4 lines
Quoted 1 line

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.

Quoted 2 lines

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
    ...
#22 lore raw

PATCH v3 1/3 t7508: .gitignore 'expect' and 'output' files

From: Junio C Hamano <[email protected]>

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 <[email protected]>
---
 t/t7508-status.sh | 78 ++++++++++---------------------------------------------
 1 file changed, 13 insertions(+), 65 deletions(-)
t/t7508-status.sh +13 -65
index 8ed5788..514df67 100755
@@ -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
Signature · 1 line
2.3.1.303.g5174db1
#23 lore raw

PATCH v3 2/3 t7508: test git status -v

In reply to Junio C Hamano

"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 <[email protected]>
---
 t/t7508-status.sh | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
t/t7508-status.sh +12 -2
index 514df67..e3c9cf9 100755
@@ -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
Signature · 1 line
2.3.1.303.g5174db1
#24 lore raw

PATCH v3 3/3 commit/status: show the index-worktree diff with -v -v

In reply to Junio C Hamano

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 <[email protected]>
---
 Documentation/git-commit.txt |  4 ++++
 t/t7508-status.sh            | 10 ++++++++++
 wt-status.c                  | 16 ++++++++++++++++
 3 files changed, 30 insertions(+)
Documentation/git-commit.txt +4 -0
index 1e74b75..f14d2ec 100644
@@ -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::
t/t7508-status.sh +10 -0
index e3c9cf9..b392376 100755
@@ -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
wt-status.c +16 -0
index 29666d0..3cdb356 100644
@@ -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)
Signature · 1 line
2.3.1.303.g5174db1
#25 lore raw

v3 cover More diffs for commit/status

In reply to Junio C Hamano

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(-)
Signature · 1 line
2.3.1.303.g5174db1
#26 lore raw

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

Quoted 8 lines · Michael J Gruber

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.

Quoted 2 lines

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

#27 lore raw

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

Quoted 11 lines · Junio C Hamano
Quoted 2 lines · Michael J Gruber

- 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;
    }
#28 lore raw

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

Quoted 8 lines · Junio C Hamano

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.

#29 lore raw

v2 cover More diffs for commit/status

In reply to Michael J Gruber

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(+)
Signature · 1 line
2.3.1.303.g5174db1