Peter Krefting <peter@xxxxxxxxxxxxxxxx> 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.
