How to prevent empty git commit --amend

How to prevent empty git commit --amend

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

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

Re: How to prevent empty git commit --amend

[Daniel Knittl-Frank]

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

Re: How to prevent empty git commit --amend

[Ivo Anjo]

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

Re: How to prevent empty git commit --amend

[Michael J Gruber]

Ivo Anjo schrieb am 13.01.2015 um 11:22:
> 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

Re: How to prevent empty git commit --amend

[Matthieu Moy]

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/

Re: How to prevent empty git commit --amend

[Ivo Anjo]

Hello,

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

Re: How to prevent empty git commit --amend

[Matthieu Moy]

Ivo Anjo <ivo.anjo@ist.utl.pt> writes:

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

Re: How to prevent empty git commit --amend

[Junio C Hamano]

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?

Re: How to prevent empty git commit --amend

[Junio C Hamano]

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

> 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+--} "$@"

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

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

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

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

[Junio C Hamano]

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?

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

> +		run_diff_files(&rev, 0);
> +	}
>  }
>  
>  static void wt_status_print_tracking(struct wt_status *s)

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

[Junio C Hamano]

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

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

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

[Michael J Gruber]

Junio C Hamano schrieb am 15.01.2015 um 21:11:
> 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.

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

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

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

[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(+)

-- 
2.3.1.303.g5174db1

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

[Michael J Gruber]

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

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

[Junio C Hamano]

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?

> +	git status -v >output &&
> +	test_cmp expect output
> +'
> +
>  test_expect_success 'setup fake editor' '
>  	cat >.git/editor <<-\EOF &&
>  	#! /bin/sh

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

[Junio C Hamano]

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?

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

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 03.03.2015 23:26:
> 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

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

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

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

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

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

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

[Junio C Hamano]

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.

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

[Michael J Gruber]

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.

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

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

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

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

    

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

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

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

[Michael J Gruber]

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

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

[Michael J Gruber]

"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

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

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

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

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

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

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

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

[Junio C Hamano]

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

> 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;
    }

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

[Junio C Hamano]

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

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