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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> From: Elijah Newren <newren@xxxxxxxxx>
>
> 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux