Re: [git 2.26] stat counts reported by commit and log are different

From: Jeff King <peff@peff.net>
Date: Apr 9, 2020, 23:12 UTC
Message-ID: <20200409231253.GA4180345@coredump.intra.peff.net>
In-Reply-To: <xmqq8sj4mfq5.fsf@gitster.c.googlers.com>

On Thu, Apr 09, 2020 at 03:55:30PM -0700, Junio C Hamano wrote:

Show 22 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > It might make sense to do so (and/or to make it possible to enable it by
> > config like we did for years with diff.renames). But it definitely is
> > way more expensive.
> > ...
> > So not quite as bad percentage-wise, but still pretty expensive. And for
> > not a huge benefit. There are ~261 impacted commits. You can see a
> > recent example with:
> >
> >   git show -B -M --stat --summary ce6521e44
> >
> > where we find that most of builtin/fmt-merge-msg.c was moved to
> > fmt-merge-msg.c. It's nice, but it's expensive enough that it probably
> > shouldn't be the default.
> 
> Not only that, it can cost correctness-wise.  Until this
> 
>   https://public-inbox.org/git/xmqqegqaahnh.fsf@gitster.dls.corp.google.com/
> 
> gets corrected, it is not advisable to enable -B and -M at the same
> time.

Ah, I forgot about that. I think the resulting diff might still be useful for a human to read, but yeah, it cannot be applied (though even there, it would be nice for it to make a little more clear to humans what's happening with the destination file).

I wonder if we ought to remove -B from its use in status/commit, but I guess there we are never generating a diff to apply, but rather one to help humans understand what happened.

-Peff