Kernel patches are usually produced by git — changes are made in the working tree, and git diff used there, or committed and then extracted from the commit(s) with git format-patch. So dontdiff probably isn’t used much; exclusions are handed by .gitignore, which is more expressive than lists of patterns for diff -X.

In your scenario, the simplest option is probably to remove the linux line from dontdiff. Longer term, if at all possible, try working in a clone of the relevant git repository and produce your patches using git.

I suspect the reason linux is included in dontdiff is that the build process can (could?) produce a binary called linux (usually it’s vmlinux). It’s possible the entry in .gitignore is incorrect — it was added for arch/um, and modified later on to apply to the root of the tree along with several other entries.

Kernel patches are usually produced by git — changes are made in the working tree, and git diff used there, or committed and then extracted from the commit(s) with git format-patch. So dontdiff probably isn’t used much; exclusions are handed by .gitignore, which is more expressive than lists of patterns for diff -X.

In your scenario, the simplest option is probably to remove the linux line from dontdiff. Longer term, if at all possible, try working in a clone of the relevant git repository and produce your patches using git.

I suspect the reason linux is included in dontdiff is that the build process can produce a binary called linux (usually it’s vmlinux, but the um “arch” links that to linux). The .gitignore entry was added for arch/um, and modified later on to apply only to the root of the tree along with several other entries.

Kernel patches are usually produced by git — changes are made in the working tree, and git diff used there, or committed and then extracted from the commit(s) with git format-patch. So dontdiff probably isn’t used much; exclusions are handed by .gitignore, which is more expressive than lists of patterns for diff -X.

In your scenario, the simplest option is probably to remove the linux line from dontdiff. Longer term, if at all possible, try working in a clone of the relevant git repository and produce your patches using git.

I suspect the reason linux is included in dontdiff is that the build process can (could?) produce a binary called linux (usually it’s vmlinux).

Kernel patches are usually produced by git — changes are made in the working tree, and git diff used there, or committed and then extracted from the commit(s) with git format-patch. So dontdiff probably isn’t used much; exclusions are handed by .gitignore, which is more expressive than lists of patterns for diff -X.

In your scenario, the simplest option is probably to remove the linux line from dontdiff. Longer term, if at all possible, try working in a clone of the relevant git repository and produce your patches using git.

I suspect the reason linux is included in dontdiff is that the build process can (could?) produce a binary called linux (usually it’s vmlinux). It’s possible the entry in .gitignore is incorrect — it was added for arch/um, and modified later on to apply to the root of the tree along with several other entries.