Re: [PATCH v2 1/3] diff-files --raw: handle intent-to-add files correctly

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2020, 18:41 UTC
Message-ID: <xmqq4kr071ch.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqy2oc8oye.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 22 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Sure, but my intention was to synchronize the `--raw` vs the `--patch`
>> output: the latter _already_ shows the correct hash. This here patch makes
>> the hash in the former's output match the latter's.
>
> That is shooting for a wrong uniformity and breaking consistency
> among the `--raw` modes.
> ...
>
> [Footnote]
>
> *1* This division of labor to free "--raw" mode of anything remotely
>     unnecessary stems from the original diff plumbing design in May
>     2005 where the "--raw" mode was the only output mode, and there
>     was a separate "git-diff-helper" (look for it in the mailing
>     list archive if you want to learn more) that reads a "--raw"
>     output and transforms it into the patch form.  That "once we
>     have the raw diff, we can pipe it to post-processing and do more
>     interesting things" eventually led to the design of the diffcore
>     pipeline where we match up (A)dded and (D)eleted entries to
>     detect renames, etc.

Having said all that.

If somebody wants to shift the burden of computing object names from the consumers of "diff --raw" output to generators like diff-files and diff-index, I do not mind if it is done under a new command line option and done consistently for not just I-T-A additions, but "modified but not added yet" and "not modified but stat information is dirty" paths. As I said, I would not recommend it, though.