Re: [PATCH v4 1/2] diff-files --raw: show correct post-image of intent-to-add files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 25, 2020, 18:21 UTC
- Message-ID
- <xmqqeeq33t2q.fsf@gitster.c.googlers.com>
- In-Reply-To
- <69256ab9107c3dba0dc007b69cc0ce98a9b91f9a.1593107621.git.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 5 quoted lines
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The documented behavior of `git diff-files --raw` is to display
>
> [...] 0{40} if creation, unmerged or "look at work tree"."on the right hand (i.e. postimage) side" is missing, which is crucial in this description.
> This happens for example when showing modified, unstaged files.
Modified I would understand. We notice that the contents on the work tree is different from what is in the index, and we tell the consumer "look at work tree". I do not think you meant "unstaged", though. If truly removed from the index, diff-files won't even know about the path. You probably meant "removed from the working tree", but 0{40} in that case means totally different thing (i.e. it would be a (D)eletion record, so 0{40} on the postimage side is a filler, not even "look at work tree"). What would make more sense to describe might be
This happens for paths that are modified, or unmodified but stat-dirty.
Either case, we tell the consumer to check the "work tree".
Show 7 quoted lines
> For intent-to-add files, we used to show the empty blob's hash instead. > In c26022ea8f5 (diff: convert diff_addremove to struct object_id, > 2017-05-30), we made that worse by inadvertently changing that to the > hash of the empty tree. > > Let's make the behavior consistent with modified files by showing > all-zero values also for intent-to-add files.
Well described.
Thanks.