Junio C Hamano:

I suspect that log.date is a small tip of an iceberg of the benefit
we'll get from this switch.

Yeah. I was planning on elaborating a bit on that, but forgot 
completely by the time I came around to look at it. I will update the 
message with your suggestions for the next version.

Some differences in the proposed output and the current output I see
are:

- the output now goes to the pager

- it now honors log.mailmap (which may default to true, so you
  could disable it with log.mailmap=false).

- it shows the ref decoration by default (when the output goes to
  terminal).

- the commit object names for the merge parents are abbreviated.

- it no longer shows the change summary (creation, deletion,
  rename, copy).

- it no longer shows the diffstat when the final commit turns out
  to be a merge commit.

There may be other differences.

I personally welcome the first four changes above, which I suspect
you didn't intend to make (I suspect that you weren't even aware of
making these changes).

I hadn't really noticed that the previous implementation *didn't* 
display this. For the most part, the final output of 'bisect' looks 
like what I expect 'show' to display, to me it was mostly missing the 
other things.

If there were no existing users of "git bisect" other than me, I
would even suggest dropping "--no-abbrev-commit" from the set of
hardcoded "git show" options, so that the commit object name itself,
just like the commit object names for the merge parents, gets
abbreviated.

The full commit hash is shown in the line above anyway, so that entire 
line is redundant. But since there is no standard format available 
that omits the commit hash I thought I'd leave it at the full hash to 
be the most like the previous behaviour as possible.

The final two changes, lack of diffstat for merges, may or may not
be considered a regression, depending on the user you ask.  I was
just surprised by them but personally was not too unhappy with the
behaviour change, but reactions from other couple of thousands of
Git users (we have at least that many users these days, no?) may be
different from mine, ranging from "Meh" to "you broke my workflow".

Those two were not intentional. I'll have to do a few test runs to 
compare the outputs and try to the change as non-intrusive as 
possible. Thanks.

If you add --stat, don't you want to add --summary as well?  Try to
bisect down to a commit that adds or removes files to see the output
difference to decide.

There are a lot of parameters to show that I have haven't used in my 
14+ years of using Git, --summary is one of them. That's why I didn't 
add it.

-- 
\\// Peter - http://www.softwolves.pp.se/