Re: [RFC/PATCH 0/9] commit: more focused advice in the no-changes-staged case

From: Thomas Rast <trast@student.ethz.ch>
Date: Jul 25, 2010, 09:22 UTC
Message-ID: <201007251122.41166.trast@student.ethz.ch>
In-Reply-To: <AANLkTilnQhsopnuAf0nja8Qq63VrOlt0_uCJrqYv5X-v@mail.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

> On Sun, Jul 25, 2010 at 00:54, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Hi,
> >
> > When last seen[1], this series was a single patch in very rough form,
> > but there have been almost no functional changes since then.
> >
> > The patches suppress most output when “git commit” is run without
> > stages changed.  So instead of
> >
> >        $ git commit
> >        # On branch master
> >        # Changed but not updated:

[...]

> >        # Untracked files:

[...]

Show 10 quoted lines

> >        no changes added to commit (use "git add" and/or "git commit -a")
> >
> > which may cause a newcomer to panic, you get
> >
> >        $ git commit
> >        no changes added to commit (use "git add" and/or "git commit -a")
> >
> > which would just cause her to scratch her head or say “oh, right!”
> > instead.  Hopefully these patches will at least provide a reminder to
> > improve the various "no changes" advice messages.

[...]

Show 5 quoted lines

> I'm not so sure about 9/9. Every time I make this mistake with "git
> commit" I find it helpful to be able to just look up to see what I
> need to stage. But perhaps the wall of text can be confusing to
> newbies, I don't have a strong opinion on whether it should be
> included or not.

I tend to agree with Ævar. I was trying a different direction yesterday, it's still WIP but you can try it from here:

  git://repo.or.cz/git/trast.git t/color-porcelain-message-output

It does not have any effect in this case because wt-status.c just printf()s "no changes added to commit", but the idea would be that it should end up in the error color (bold red by default) so that it stands out clearly.

[I actually wrote it because for git-rebase it's even worse: if you have fixed one conflict and immediately hit another, the output is

  Recorded resolution for 'dir/a'.
  [detached HEAD aa9ae6b] related change                          (1)
   1 files changed, 1 insertions(+), 1 deletions(-)
  Automatic cherry-pick failed.  After resolving the conflicts,
  mark the corrected paths with 'git add <paths>', and
  run 'git rebase --continue'
  Recorded preimage for 'dir/a'
  Could not apply 649420f... second                               (2)

(1) is the subject of the just-applied commit, whereas (2) is the subject of the now-conflicted commit. In my case (1) caught my eye for some reason and I had to look three times to figure out that (2) was the interesting part. Now it's in red!]

-- 
Thomas Rast
trast@{inf,student}.ethz.ch