mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Jeff King <>
Cc: Christian Couder <>,
	Bartosz Baranowski <>,
Subject: Re: [PATCH 3/3] bisect: make diff-tree output prettier
Date: Fri, 22 Feb 2019 09:49:44 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Jeff King's message of "Fri, 22 Feb 2019 01:23:28 -0500")

Jeff King <> writes:

> After completing a bisection, we print out the commit we found using an
> internal version of diff-tree. The result is aesthetically lacking:
>   - it shows a raw diff, which is generally less informative for human
>     readers than "--stat --summary" (which we already decided was nice
>     for humans in format-patch's output).
>   - by not abbreviating hashes, the result is likely to wrap on most
>     people's terminals
>   - we don't use "-r", so if the commit touched files in a directory,
>     you only get to see the top-level directory mentioned
>   - we don't specify "--cc" or similar, so merges print nothing (not
>     even the commit message!)
> Even though bisect might be driven by scripts, there's no reason to
> consider this part of the output as machine-readable (if anything, the
> initial "$hash is the first bad commit" might be parsed, but we won't
> touch that here). Let's make it prettier and more informative for a
> human reading the output.

Sounds very sensible.  One potential point that makes me worried is
this move might tempt people to make the output even larger (e.g. a
full diff with "--patch" is overkill if done unconditionally).

> While we're tweaking the options, let's also switch to using the diff
> "ui" config. If we're accepting that this is human-readable output, then
> we should respect the user's options for how to display it.
> ...
> If we do care about the change in exit code from bisect, then it
> probably does make sense to go with an external process. Then it can
> happily die on the corruption, while bisect continues with the rest of
> the high-level operation. I'm not sure it really matters much, though.
> Once your repository is corrupted, all bets are off. It's nice that we
> can bisect in such a state at all.

This is about showing the very final message after finding which one
is the culprit.  Is there any other "clean-up" action we need to do
after showing the message?  I do not care too much about the exit
code from the bisection, but if dying from diff-tree can interfere
with such a clean-up, that would bother me a lot more, and at that
point, given especially that this is not a performance sensitive
thing at all (it is not even invoked log(n) times---just once at the
end), moving to external process may make it a lot simpler and

  reply	other threads:[~2019-02-22 17:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 10:47 git bisect - good vs bad output is different Bartosz Baranowski
2019-02-21 21:39 ` Junio C Hamano
2019-02-22  6:19   ` [PATCH 0/3] prettier bisect output Jeff King
2019-02-22  6:20     ` [PATCH 1/3] bisect: use string arguments to feed internal diff-tree Jeff King
2019-02-22  6:21     ` [PATCH 2/3] bisect: fix internal diff-tree config loading Jeff King
2019-03-03 17:59       ` Christian Couder
2019-03-05  4:15         ` Jeff King
2019-02-22  6:23     ` [PATCH 3/3] bisect: make diff-tree output prettier Jeff King
2019-02-22 17:49       ` Junio C Hamano [this message]
2019-02-23 13:44         ` Jeff King
2019-03-03 18:25           ` Christian Couder
2019-02-22 17:39     ` [PATCH 0/3] prettier bisect output Junio C Hamano
2019-03-03 18:33     ` Christian Couder
2019-03-05  4:16       ` Jeff King

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).