patch, 2 partsRe: [PATCH 1/2] Suggest use of "git add file1 file2" when there is nothing to commit.

If a user modifies files and runs 'git commit' (without the very useful -a option) and they have not yet updated the index they are probably coming from another SCM-like tool which would perform the same as 'git commit -a' in this case. Showing the user their current status and a final line of "nothing to commit" is not very reassuring, as the user might believe that Git did not recognize their files were modified.

Instead we can suggest as part of the 'nothing to commit' message that the user invoke 'git add' to add files to their next commit.

Suggested by Andy Parkins' Git 'niggles' list (<200612132237.10051.andyparkins@gmail.com>).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-commit.sh |    2 +-
 wt-status.c   |   11 ++++++-----
 2 files changed, 7 insertions(+), 6 deletions(-)

Hi,

Am Freitag, den 15.12.2006, 21:53 -0500 schrieb Shawn O. Pearce: ...

I don't like the new 'nothing to commit (use "git add ... message")' message. I use git status very often to see if there is something to commit, but now there is always this annoying "use git add ..." message. I just want to see on what the branch is and if there is something to commit.

If there is something to commit I get the list of untracked or modified files with the use_add_msg and if I try to commit an empty tree as initial commit I get the message from git-commit.sh.

bye

Michael Loeffler <zvpunry@zvpunry.de> writes:

I tend to not like _ANY_ change at all, but I've learned to wait and see if I get used to it when I see something that annoys me initially, to see if the annoyance is because what it does is truly wrong or it is because what it does is merely different from what I am used to.

So I've been trying it out myself as one of the guinea pigs on this one as well.

So far, my judgement is that this is of the better kind; it is easy to get used to, and once you get used to it, it is easily ignorable.

Other people's tastes may differ, of course.

Junio C Hamano <junkio@cox.net> writes:

How about doing this?

-- >8 -- git-status: squelch "use 'git add file...'" message when unneeded

Add a field in wt_status to record if there are any uncached changes, and use it to decide when there is no point to add the "use 'git add'" message.

---

Junio C Hamano writes:
 > Junio C Hamano <junkio@cox.net> writes:
 > 
 > > Michael Loeffler <zvpunry@zvpunry.de> writes:
 > >
 > >> Am Freitag, den 15.12.2006, 21:53 -0500 schrieb Shawn O. Pearce:
 > >> ...
 > >>> +		printf("%s (%s)\n",
 > >>> +			s->amend ? "# No changes" : "nothing to commit",
 > >>> +			use_add_msg);
 > >>>  }
 > >> I don't like the new 'nothing to commit (use "git add ... message")'
 > >> message. I use git status very often to see if there is something to
 > >> commit, but now there is always this annoying "use git add ..." message.
 > >
 > > I tend to not like _ANY_ change at all, but I've learned to wait
 > > and see if I get used to it when I see something that annoys me
 > > initially, to see if the annoyance is because what it does is
 > > truly wrong or it is because what it does is merely different
 > > from what I am used to.
 > >
 > > So I've been trying it out myself as one of the guinea pigs on
 > > this one as well.
 > >
 > > So far, my judgement is that this is of the better kind; it is
 > > easy to get used to, and once you get used to it, it is easily
 > > ignorable.
 > 
 > How about doing this?
 > 
 > -- >8 --
 > git-status: squelch "use 'git add file...'" message when unneeded
 > 
 > Add a field in wt_status to record if there are any uncached
 > changes, and use it to decide when there is no point to add the
 > "use 'git add'" message.

Commit 6e458bf63f48fb7d15cb70ad7c7b7b71915d94a2 in next is already doing exactly that. Or am I missing something?

Juergen Ruehle <j.ruehle@bmiag.de> writes:

If there is something you are missing, it is that I am overloaded these days ;-).

Thanks for the reminder.

Junio C Hamano writes:
 > If there is something you are missing, it is that I am
 > overloaded these days ;-).

I'm sorry. As a rather unsuccessful former maintainer of http://www.openarchitectureware.org/ I can fully appreciate git's luck to have such a dedicated maintainer.

Juergen Ruehle <j.ruehle@bmiag.de> writes:

Actually there is one difference that I found practically important. It usually is a norm for me to have a handful untracked files that I do not even bother adding to .gitignore in the repository. My patch does not suggest "add" when there are untracked files but no locally modified files.

Junio C Hamano writes:
 > Juergen Ruehle <j.ruehle@bmiag.de> writes:
 > 
 > > Junio C Hamano writes:
 > >  > If there is something you are missing, it is that I am
 > >  > overloaded these days ;-).
 > >
 > > I'm sorry. As a rather unsuccessful former maintainer of
 > > http://www.openarchitectureware.org/ I can fully appreciate git's luck
 > > to have such a dedicated maintainer.
 > 
 > Actually there is one difference that I found practically
 > important.  It usually is a norm for me to have a handful
 > untracked files that I do not even bother adding to .gitignore
 > in the repository.  My patch does not suggest "add" when there
 > are untracked files but no locally modified files.

Yes. I don't have a real preference. I have a slight suspicion that the hint is useful for newbies because having only untracked files is the initial situation, but the hint in my patch is actually wrong because git-commit won't help in this situation. Do you want to revert the patch and apply yours or should I send a correction?

Juergen Ruehle <j.ruehle@bmiag.de> writes:

I think it is Ok to give hints for untracked files -- with experience eyes will learn to ignore them but by then they do not need hints. Please send in a correction as appropriate.

From: =?utf-8?q?J=C3=BCrgen_R=C3=BChle?= <j-r@online.de>

Since 98bf8a47c296f51ea9722fef4bb81dbfb70cd4bb status would claim that git-commit could be useful even if there are no changes except untracked files.

Since wt-status is already computing all the information go the whole way and separately track the (non-)emptiness of all three sections, unify the code, and provide separate messages for each case. This adds a new message for the untracked only case and adds an explanation for a completely empty working directory during initial commit.

This change is effectively reverting 98bf8a47c296f51ea9722fef4bb81dbfb70cd4bb and replacing it by a cleaner version.

Signed-off-by: Jürgen Rühle <j-r@online.de>
---
  Junio C Hamano writes:
   > I think it is Ok to give hints for untracked files -- with
   > experience eyes will learn to ignore them but by then they do
   > not need hints.  Please send in a correction as appropriate.

  This should provide useful feedback for the nothing to commit case in any
  situation. It is how I should have done it initially. Sorry for wasting your
  time.

  Still missing:

   - Further changes to the header messages (as discussed on the list)

   - Patches to every other file that contains these messages verbatim

     (AFAICS this affects only the git-reset man page, tutorial-2 and the VIM
      syntax highlighting)

 wt-status.c |   21 ++++++++++++---------
 wt-status.h |    6 ++++--
 2 files changed, 16 insertions(+), 11 deletions(-)

Juergen Ruehle writes:
 > [Corrupted patch deleted]

Will try again when I know what happened.

Juergen Ruehle writes:
 > Juergen Ruehle writes:
 >  > [Corrupted patch deleted]

Actually the patch is ok as sent (somehow my MUA was adding CRs when locally saving the patch). Sorry for the noise.

Juergen Ruehle <j.ruehle@bmiag.de> writes:

While you are at it, let me point out one thing that has been annoying me for a while.

This is an example e-mail I have been getting from you (the below is before decoding MIME):

  From: Juergen Ruehle <j.ruehle@bmiag.de>
  Subject: [PATCH] Provide better feedback for the ...
  Date: Wed, 10 Jan 2007 08:08:12 +0100
  Message-ID: <1168412892113-git-send-email-j.ruehle@bmiag.de>
  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: quoted-printable
  Cc: git@vger.kernel.org,
          =?utf-8?q?J=C3=BCrgen_R=C3=BChle?= <j-r@online.de>
  X-Mailer: git-send-email 1.5.0.rc0.g525e

  From: =3D?utf-8?q?J=3DC3=3DBCrgen_R=3DC3=3DBChle?=3D <j-r@online.de>

  Since 98bf8a47c296f51ea9722fef4bb81dbfb70cd4bb status would claim that
  git-commit could be useful even if there are no changes except untracked =
  files.

  Since wt-status is already computing all the information go the whole way=
   and
  separately track the (non-)emptiness of all three sections, unify the cod=
  e, and
  provide separate messages for each case. This adds a new message for the
  untracked only case and adds an explanation for a completely empty workin=
  g
  directory during initial commit.

  This change is effectively reverting 98bf8a47c296f51ea9722fef4bb81dbfb70c=
  d4bb
  and replacing it by a cleaner version.

  Signed-off-by: J=C3=BCrgen R=C3=BChle <j-r@online.de>

Notice:

 * The message claims to be from git-send-email;

 * Content-Type and CTE are UTF-8 and QP (which is fine);

 * You have in-body From: line; this is not wrong per-se and I
   understand why you would want one (your e-mail From: line
   uses ASCII approximations "ue" and "ue" and you would want
   the resulting commit to spell your name correctly).

 * However, this in-body From: line is _doubly_ QP encoded (what
   you see above is your name, first RFC 2047 encoded and then
   QP encoded).  It shouldn't be.

So, my questions are:

 (1) is this what git-send-email generates and sends out by
     default?  If so that means it is a bug in that program that
     needs to be fixed.

 (2) if not, are you inserting the in-body From: by hand,
     perhaps cut & paste from format-patch output, before
     feeding git-send-email (which runs QP on it)?

If the latter, please do not paste the RFC 2047 quoted form. You can spell your name in raw UTF-8 on the in-body From: line just like you did on your Signed-off-by: line.

Junio C Hamano writes:
 > Juergen Ruehle <j.ruehle@bmiag.de> writes:
 > 
 > > Juergen Ruehle writes:
 > >  > [Corrupted patch deleted]
 > >
 > > Will try again when I know what happened.
 > 
 > While you are at it, let me point out one thing that has been
 > annoying me for a while.
 > 
 >  * The message claims to be from git-send-email;
 > 
 >  * Content-Type and CTE are UTF-8 and QP (which is fine);
 > 
 >  * You have in-body From: line; this is not wrong per-se and I
 >    understand why you would want one (your e-mail From: line
 >    uses ASCII approximations "ue" and "ue" and you would want
 >    the resulting commit to spell your name correctly).
 >
 >  * However, this in-body From: line is _doubly_ QP encoded (what
 >    you see above is your name, first RFC 2047 encoded and then
 >    QP encoded).  It shouldn't be.
 > 
 > So, my questions are:
 > 
 >  (1) is this what git-send-email generates and sends out by
 >      default?  If so that means it is a bug in that program that
 >      needs to be fixed.
 > 
 >  (2) if not, are you inserting the in-body From: by hand,
 >      perhaps cut & paste from format-patch output, before
 >      feeding git-send-email (which runs QP on it)?
 > 
 > If the latter, please do not paste the RFC 2047 quoted form.
 > You can spell your name in raw UTF-8 on the in-body From: line
 > just like you did on your Signed-off-by: line.

Yes, this is using git-send-email which sends the mail as 8bit encoded and provides the QP encoded From line. Unfortunately there seems to be a gateway in between that doesn't handle 8bit and QPs the mail again. Perhaps I need some other switches for format-patch and send-email to produce a better result? I'll take another look at the documentation before annoying you again.

From: Jürgen_Rühle <j-r@online.de>

Signed-off-by: Jürgen Rühle <j-r@online.de>
---
 This is just a hack since I know next to nothing about perl.

 git-send-email.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Juergen Ruehle writes:
 > From: Jürgen_Rühle <j-r@online.de>
                ^

Ok, i should have also reverted the ' ' to '_' conversion, but it seems that send-email is to blame, because it simply copies the (possibly) QP encoded author address into the body of a (possibly) not QP encoded message.

 > Signed-off-by: Jürgen Rühle <j-r@online.de>
 > ---
 >  This is just a hack since I know next to nothing about perl.
 > 
 >  git-send-email.perl |    1 +
 >  1 files changed, 1 insertions(+), 0 deletions(-)
 > 
 > diff --git a/git-send-email.perl b/git-send-email.perl
 > index ba39d39..a4a22d3 100755
 > --- a/git-send-email.perl
 > +++ b/git-send-email.perl
 > @@ -555,6 +555,7 @@ foreach my $t (@files) {
 >  	}
 >  	close F;
 >  	if (defined $author_not_sender) {
 > +		$author_not_sender =~ s/=\?utf-8\?q\?([^?]*)\?=/my $bla = $1; $bla =~ s|=([0-9a-fA-F]{2})|sprintf '%c', hex($1)|eg; $bla/eg;

+		$author_not_sender =~ s/=\?utf-8\?q\?([^?]*)\?=/my $bla = $1; $bla =~ s|_| |g; $bla =~ s|=([0-9a-fA-F]{2})|sprintf '%c', hex($1)|eg; $bla/eg;

 >  		$message = "From: $author_not_sender\n\n$message";
 >  	}
 >  
 > -- 
 > 1.5.0.rc0.g525e

Juergen Ruehle <j.ruehle@bmiag.de> writes:

Thanks. I think other people would want to hack on this, so I would make a separete sub to make it easier, like this:

hi,

Am Mittwoch, den 10.01.2007, 08:08 +0100 schrieb Juergen Ruehle: ...

...

Shouldn't the user know that there is nothing in his working directory?

How about s/matches HEAD/clean/

There is another thing: # Changed but not added: # (use "git add <file>..." to incrementally add content to commit) # # deleted: blah

How about adding some more hints (e.g.: git rm --cached <file>) depending on the diff_queue in wt_status_print_changed_cb()?

bye michael

Michael Loeffler writes:
 > hi,
 > 
 > Am Mittwoch, den 10.01.2007, 08:08 +0100 schrieb Juergen Ruehle:
 > ...
 > > @@ -311,12 +312,14 @@ void wt_status_print(struct wt_status *s)
 > ...
 > > +		else if (s->is_initial)
 > > +			printf("nothing to commit (working directory is empty)\n");
 > Shouldn't the user know that there is nothing in his working directory?

:-)

Well this is the state directly after git-init, e.g. the very first contact with git. Perhaps we should write:

nothing to commit (create files in the working directory and use git add)

 > > +		else
 > > +			printf("nothing to commit (working directory matches HEAD)\n");
 > How about s/matches HEAD/clean/

I like that.

 > There is another thing:
 > # Changed but not added:
 > #   (use "git add <file>..." to incrementally add content to commit)
 > #
 > #       deleted:    blah
 > 
 > How about adding some more hints (e.g.: git rm --cached <file>)
 > depending on the diff_queue in wt_status_print_changed_cb()?

Yes, there's always one more case to consider:-)

From: Jürgen Rühle <j-r@online.de>

Since 98bf8a47c296f51ea9722fef4bb81dbfb70cd4bb status would claim that git-commit could be useful even if there are no changes except untracked files.

Since wt-status is already computing all the information needed go the whole way and actually track the (non-)emptiness of all three sections separately, unify the code, and provide useful messages for each individual case.

Thanks to Junio and Michael Loeffler for suggestions.

Signed-off-by: Jürgen Rühle <j-r@online.de>
---
  This is a resend of the nothing-to-commit improvement patch (hopefully)
  without corruption. This also includes some changes due to feedback from
  Michael Loeffler.

  Still missing:

   - Further changes to the other messages (as discussed on the list)

   - Patches to other files that contain these messages verbatim

     (AFAICS this affects only the git-reset man page, tutorial-2 and the VIM
      syntax highlighting)

 wt-status.c |   21 ++++++++++++---------
 wt-status.h |    6 ++++--
 2 files changed, 16 insertions(+), 11 deletions(-)

On Wed, Jan 10, 2007 at 11:25:03PM +0100, Juergen Ruehle wrote:

I have been tracking these changes for the vim highlighting, but have been waiting for things to settle before sending a patch (which should hopefully go into v1.5.0, but I will wait until this is finalized).

-Peff

Jeff King writes:
 > On Wed, Jan 10, 2007 at 11:25:03PM +0100, Juergen Ruehle wrote:
 > 
 > >    - Patches to other files that contain these messages verbatim
 > >      (AFAICS this affects only the git-reset man page, tutorial-2 and the VIM
 > >       syntax highlighting)
 > 
 > I have been tracking these changes for the vim highlighting, but have
 > been waiting for things to settle before sending a patch (which should
 > hopefully go into v1.5.0, but I will wait until this is finalized).

Thanks for tracking this. It would be nice if we could make the syntax highlighting less dependent on the exact wording.

Michael Loeffler writes:
 > Hi,
 > 
 > Am Freitag, den 15.12.2006, 21:53 -0500 schrieb Shawn O. Pearce:
 > ...
 > > @@ -292,7 +291,9 @@ void wt_status_print(struct wt_status *s)
 > >  	if (s->verbose && !s->is_initial)
 > >  		wt_status_print_verbose(s);
 > >  	if (!s->commitable)
 > > -		printf("%s\n", s->amend ? "# No changes" : "nothing to commit");
 > > +		printf("%s (%s)\n",
 > > +			s->amend ? "# No changes" : "nothing to commit",
 > > +			use_add_msg);
 > >  }
 > I don't like the new 'nothing to commit (use "git add ... message")'
 > message. I use git status very often to see if there is something to
 > commit, but now there is always this annoying "use git add ..." message.
 > I just want to see on what the branch is and if there is something to
 > commit.
 > 
 > If there is something to commit I get the list of untracked or modified
 > files with the use_add_msg and if I try to commit an empty tree as
 > initial commit I get the message from git-commit.sh.

I'd appreciate feedback on my series from the 2nd of January, especially part 3/4 (Subject: [PATCH 3/4] Improve "nothing to commit" part of status output). This is already part of next.

It removes the message if there really is nothing to commit and replaces it by a generic pointer to git add and git commit if there are pending changes in the working directory.

hi,

Am Samstag, den 06.01.2007, 15:02 +0100 schrieb Juergen Ruehle: ...

A very positive feedback from me, I like this and it is much better then just removing this "use git add"-message. ;)

bye michael

Michael Loeffler writes:
 > hi,
 > 
 > Am Samstag, den 06.01.2007, 15:02 +0100 schrieb Juergen Ruehle:
 > ...
 > > I'd appreciate feedback on my series from the 2nd of January,
 > > especially part 3/4 (Subject: [PATCH 3/4] Improve "nothing to commit"
 > > part of status output). This is already part of next.
 > A very positive feedback from me, I like this and it is much better then
 > just removing this "use git add"-message. ;)

How about Junio's case where there are only untracked files in the working directory? I tend to send a patch that either just prints "nothing to commit" (simpler) or provides a different message that just advertises git-add.