From: Jonathan Nieder <jrnieder@gmail.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "Jakub Narebski" <jnareb@gmail.com>,
"Jeff King" <peff@peff.net>
Subject: Making error messages stand out (Re: [RFC/PATCH 0/9] commit: more focused advice in the no-changes-staged case)
Date: Thu, 29 Jul 2010 18:51:51 -0500 [thread overview]
Message-ID: <20100729235151.GB6623@burratino> (raw)
In-Reply-To: <201007251122.41166.trast@student.ethz.ch>
Thomas Rast wrote:
> git://repo.or.cz/git/trast.git t/color-porcelain-message-output
My first thought was "that’s a horrible idea; red text is so hard to
read". My second thought: "oh, maybe it’s not so bad because it’s
bold". Now I am starting to worry about the sort of distraction that
can sometimes follow from too much formatting (e.g., with certain
syntax highlighting engines).
A little bold text here and there (maybe to highlight the heading
strings like "fatal" and "hint") would be very useful, certainly. To
deal with messages like
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)
though, I find the best solution is to use short, formulaic messages:
...
Recorded resolution for 'dir/a'.
[detached HEAD aa9ae6b] related change
1 files changed, 1 insertions(+), 1 deletions(-)
fatal: could not apply 649420f... second
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' and run 'git rebase --continue'
I do realize this is not a very useful thing to say without attaching
a patch. ;-)
next prev parent reply other threads:[~2010-07-29 23:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-25 0:54 [RFC/PATCH 0/9] commit: more focused advice in the no-changes-staged case Jonathan Nieder
2010-07-25 0:56 ` [PATCH 1/9] wt-status: split wt_status_print into digestible pieces Jonathan Nieder
2010-07-25 0:57 ` [PATCH 2/9] wt-status: split off a function for printing submodule summary Jonathan Nieder
2010-07-25 0:58 ` [PATCH 3/9] commit: split off a function to fetch the default log message Jonathan Nieder
2010-07-25 0:58 ` [PATCH 4/9] commit: split commit -s handling into its own function Jonathan Nieder
2010-07-25 0:59 ` [PATCH 5/9] commit: split off the piece that writes status Jonathan Nieder
2010-07-25 0:59 ` [PATCH 6/9] t7508 (status): modernize style Jonathan Nieder
2010-07-25 8:38 ` Ævar Arnfjörð Bjarmason
2010-07-25 1:00 ` [PATCH 7/9] commit: give empty-commit avoidance code its own function Jonathan Nieder
2010-07-25 1:01 ` [PATCH 8/9] commit --dry-run: give advice on empty amend Jonathan Nieder
2010-07-25 1:02 ` [PATCH 9/9] commit: suppress status summary when no changes staged Jonathan Nieder
2010-08-11 7:11 ` Thomas Rast
2010-08-11 7:30 ` Jonathan Nieder
2010-08-11 7:49 ` [PATCH v2] t6040 (branch tracking): check “status” instead of “commit” Jonathan Nieder
2010-08-12 0:45 ` Ævar Arnfjörð Bjarmason
2010-08-11 12:15 ` [PATCH 9/9] commit: suppress status summary when no changes staged Ævar Arnfjörð Bjarmason
2010-08-11 23:57 ` Jonathan Nieder
2010-08-12 0:05 ` Ævar Arnfjörð Bjarmason
2010-08-12 0:10 ` Jonathan Nieder
2010-07-25 8:54 ` [RFC/PATCH 0/9] commit: more focused advice in the no-changes-staged case Ævar Arnfjörð Bjarmason
2010-07-25 9:22 ` Thomas Rast
2010-07-29 23:51 ` Jonathan Nieder [this message]
2010-07-30 18:44 ` Making error messages stand out (Re: [RFC/PATCH 0/9] commit: more focused advice in the no-changes-staged case) Sverre Rabbelier
2010-08-11 8:31 ` [WIP/PATCH 0/4] Re: Making error messages stand out Jonathan Nieder
2010-08-11 8:36 ` [PATCH 1/4] Eliminate “Finished cherry-pick/revert” message Jonathan Nieder
2010-08-11 8:36 ` [PATCH 2/4] Introduce advise() to print hints Jonathan Nieder
2010-08-11 8:37 ` [PATCH 3/4] cherry-pick/revert: Use error() for failure message Jonathan Nieder
2010-08-11 8:37 ` [PATCH 4/4] cherry-pick/revert: Use advise() for hints Jonathan Nieder
2010-08-11 9:21 ` [WIP/PATCH 0/4] Re: Making error messages stand out Nguyen Thai Ngoc Duy
2010-08-11 9:39 ` Matthieu Moy
2010-08-11 9:58 ` Nguyen Thai Ngoc Duy
2010-08-11 17:34 ` Sverre Rabbelier
2010-08-18 14:36 ` [PATCH] tests: fix syntax error in "Use advise() for hints" test Ævar Arnfjörð Bjarmason
2010-08-19 4:30 ` Jonathan Nieder
2010-08-19 12:22 ` Ævar Arnfjörð Bjarmason
2010-08-20 10:13 ` Raja R Harinath
2010-08-20 14:22 ` Ævar Arnfjörð Bjarmason
2010-08-20 17:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100729235151.GB6623@burratino \
--to=jrnieder@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=peff@peff.net \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.