Re: quiltimport mode detection oddity

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2024, 00:33 UTC
Message-ID: <xmqqed77hifn.fsf@gitster.g>
In-Reply-To: <20240801155702.70242c31d476c46c84ee11a3@linux-foundation.org>

Andrew Morton <akpm@linux-foundation.org> writes:

Show 16 quoted lines

> hp2:/usr/src/mm> git quiltimport --series series
> tools-separate-out-shared-radix-tree-components.patch
> warning: tools/testing/radix-tree/generated/autoconf.h has type 100644, expected 100664
>
>
>
>
> That patch has
>
> diff --git a/tools/testing/radix-tree/generated/autoconf.h a/tools/testing/radix-tree/generated/autoconf.h
> deleted file mode 100664
> --- a/tools/testing/radix-tree/generated/autoconf.h
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -#include "bit-length.h"
> -#define CONFIG_XARRAY_MULTI 1

So, the patch removes autoconf.h file from that directory. The "extended header" part between "diff --git" and "--- a/..." has "deleted file mode 100664" and that is where the warning comes.

I do not quite recall at which point "git quiltimport" calls "git apply", but the "has type 100644, expected 100664" does ring a bell.

> after quiltimport:
>
> hp2:/usr/src/mm> ls -l tools/testing/radix-tree/generated/autoconf.h
> ls: cannot access 'tools/testing/radix-tree/generated/autoconf.h': No such file or directory

That is to be expected, if that patch was successfully applied, no? After all, the patch you quoted above seems to be a removal of autoconf.h from that path.

> I can't figure what I've done to make quiltimport (git-apply?) think that the file
> had 100644 permissions.  Maybe the lack of an index line tripped it up.

You said "That patch has", and I take it to mean that the input material before "git quiltimport" touched it already had the extended header that records the removal of a file whose mode is 100664?

And lack of the index line is probably a red herring. EVen if there were an index line, it would just have recorded the two object names (the blob object name of the original contents before removal, followed by a double-dot "..", followed by all-0 to signal removal). We do not read mode bits out of that line.

> (btw, "has type" should be "has permissions" in that message, no?)

If leading prefix 100 did not exist, yes, permissions would be more appropriate, but if the prefix changed from 100644 to say 120000, that would be a type change from plain blob to a symlink. So "type" is not quite wrong, either.