On Fri, Feb 24, 2023 at 11:32 AM Andrew Morton akpm@linux-foundation.org wrote:

Can we use git instead of diff? I tried once, but it didn't work - perhaps because it didn't like doing stuff outside a git repo.

Just using "git diff" does work *but* I would strongly suggest using "--no-index" as in

git diff --no-index -- path1 path2

because without the "--no-index" you will find that "git diff" will use heuristics to decide what it is you want to do.

So if you do just

git diff path1 path2

and both of those paths are *inside* a git directory, then git thinks that "oh, you want to see the diff of those two paths against the current git index", and does something *very* different from showing the diff between those two paths.

And I suspect that is the exact reason you *thought* it didn't work, but now that you tried it in a new test-directory, it did work for you.

With the "--no-index", the ambiguity of "do you want a diff against git state, or the files against each other" goes away

Just to give another example of this:

(a) when I'm in my kernel tree, I can do

$ git diff .config /etc/kernel-config

and it will show me the diff between the two files, because while my ".config" file is inside the repository, "/etc/kernel-config" is clearly not, so I get that "diff between two files" behavior.

(b) but then if I do a conceptually similar

$ git diff .config arch/x86/configs/x86_64_defconfig

then git will see that both paths *are* inside the repository, and think I'm doing a diff vs the git index state, and since I have no changes wrt any checked in state in any paths that match, it will show no diff at all.

So if I actually want to see the file diff between those two paths, I have to do

$ git diff --no-index .config arch/x86/configs/x86_64_defconfig

to clarify what it is that I want.

Also note that "git diff" is *not* a replacement for the 'diff' binary from diffutils in general.

Doing a 'git diff' will *only* generate the extended git unified diffs. There's no support for any other diff format, and while there is overlap in the command line switches, there's a lot of differences too.

So "git diff" is very much a "you can use it as a replacement for plain 'diff', but only in very specific circumstances" thing.

Linus

On Fri, Feb 24, 2023 at 12:20 PM Paul Eggert eggert@cs.ucla.edu wrote:

Thanks for pointing this out. I added this to our list of things to do, by installing the attached patch to the GNU diffutils TODO file. If this patch's wording isn't right, please let me know, as I haven't read this whole email thread, just the three emails sent directly to me.

Looks good to me.

The whole thread isn't actually any more interesting, it was mainly a lot of "how did the bits get lost" confusion because it wasn't clear whether it was some local script or quilt or whatever that lost sight of the executable bit.

It starts with a report about how the lost bit results in a build error at

https://lore.kernel.org/lkml/adc1b0b7-f837-fbb4-332b-4ce18fc55709@roeck-us.n...

and there's discussion about how this has happened before and how our kernel Makefiles generally should try to not execute scripts directly exactly because our ancient "tarballs and patches" model never supported the executable bit etc.

So none of it is very relevant, except in the sense that it would be convenient if diffutils did support the executable bit changes and we wouldn't have these kinds of things happening every once in a blue moon.

Again - there are multiple different workarounds, ranging from "we shouldn't do that then in our makefiles" to "you can use 'git diff' instead in the quilt scripts".

So not a huge deal - but it would just be nice if diffutils just supported the extended format.

Linus