Thread (2 messages) 2 messages, 2 authors, 2022-09-01

Re: [PATCH 1/3] diff: have submodule_format logic avoid additional diff headers

From: Elijah Newren <hidden>
Date: 2022-09-01 03:45:11

Possibly related (same subject, not in this thread)

On Wed, Aug 31, 2022 at 3:20 PM Junio C Hamano [off-list ref] wrote:
"Elijah Newren via GitGitGadget" [off-list ref] writes:
quoted
From: Elijah Newren <redacted>

Commit 95433eeed9 ("diff: add ability to insert additional headers for
paths", 2022-02-02) introduced the possibility of additional headers,
created in create_filepairs_for_header_only_notifications().  These are
represented by inserting additional pairs in diff_queued_diff which
always have a mode of 0 and a null_oid.  When these were added, one
code path was noted to assume that at least one of the diff_filespecs
in the pair were valid, and that codepath was corrected.

The submodule_format handling is another codepath with the same issue;
it would operate on these additional headers and attempt to display them
as submodule changes.  Prevent that by explicitly checking for both
modes being 0.
It may make sense to give a concrete name for the condition these
new codepaths check, which presumably exists in the part that was
touched in 95433eeed9 when "that codepath was corrected".  I think
you want to treat a diffpair with at least one side with non-zero
mode as a "real" thing (as opposed to the phony "additional headers"
hack), so perhaps

        int diff_filepair_is_phoney(struct diff_filespec *one,
                                    struct diff_filespec *two)
        {
                return !DIFF_FILE_VALID(one) && !DIFF_FILE_VALID(two);
        }

or something like that.  The use of the FILE_VALID macro here is
very much deliberate, and tries to match the more recent hack after
this hunk that says:

        if (!DIFF_FILE_VALID(one) && !DIFF_FILE_VALID(two)) {
                /*
                 * We should only reach this point for pairs from
                 * create_filepairs_for_header_only_notifications().  For
                 * these, we should avoid the "/dev/null" special casing
                 * above, meaning we avoid showing such pairs as either
                 * "new file" or "deleted file" below.
                 */
                lbl[0] = a_one;
                lbl[1] = b_two;
        }

We shouldn't expect readers to understand (one->mode || two->mode)
is about the same hack as the other one.
I like that; I'll make that change.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help