Subject: Re: bisect does not respect 'log.date'

From: Junio C Hamano <[email-masked]>
Date: Mon, 25 Mar 2024 14:49:46 -0700

Peter Krefting <[email-masked]> writes:

> The question is what is the correct way of fixing this; is it to make
> "git diff-tree --pretty" respect the "log.date" option, or to make

The "diff-tree" and other "plumbing" commands deliberately ignore
configuration and the point of doing so is to make sure their output
are stable without getting affected by the end-user configuration.

> "git bisect" pass a --date pate parameter to the invocation of it?

If we were to change how "bisect" reports the date of the commit,
this is a more reasonable route to go.

Are you sure that nobody is driving "git bisect" from a script and
scraping the output in such a way that a change in the output format
would break such a script?  I would say it is unlikely (they may be
scraping the output to find a commit by looking for 40-hex string,
though) that it would cause such a breakage.

But stepping back a bit.

If "git bisect" were written in the more modern era, I am reasonably
sure that it wouldn't have used "git diff-tree" when reporting the
"first bad commit".  It would have used "git show" instead, which is
at the Porcelain level and will pay attention to the configuration
variables.  Instead of focusing too narrowly on the log.date option,
that would only tweak the date format, it may be a more fruitful way
to invest brainwaves in to consider the feasibility of switching to
use "git show" there.