Hi!
On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
quoted
On 2026-02-07T23:00:49+0100, наб wrote:
quoted
Signed-off-by: Ahelenia Ziemiańska <redacted>
For some reason, the patch doesn't want to apply. I don't see anything
obviously wrong, so it may be an issue in my side?
Applying: futex_waitv.2: new page
error: affected file 'man2/futex_waitv.2' is beyond a symbolic link
error: man7/futex.7: does not exist in index
Patch failed at 0001 futex_waitv.2: new page
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Press any key to continue...
Hm, I did recently set
$ git config diff.noprefix
true
I didn't expect this to affect format-patch diffs
(since it doesn't affect diffs shown by git add -p),
or, if it did, I expected the designated consumer of format-patch
diffs (am) to understand this. perhaps not;
maybe -p0 to git am?
A quick search yields
https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#eaa0323ec4eed441b37caf96e1b136529b298dbac
where you're in the thread and the maintainer says "queued" for a patch
that would ignore noprefix for format-patch for this reason precisely.
But clearly not, since my patches were with noprefix=true and came out -p0.
On Tue, Feb 10, 2026, at 15:30, Alejandro Colomar wrote:
Hi!
On 2026-02-10T15:17:55+0100, наб wrote:
quoted
Hi!
On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
quoted
On 2026-02-07T23:00:49+0100, наб wrote:
quoted
Signed-off-by: Ahelenia Ziemiańska <redacted>
For some reason, the patch doesn't want to apply. I don't see anything
obviously wrong, so it may be an issue in my side?
Applying: futex_waitv.2: new page
error: affected file 'man2/futex_waitv.2' is beyond a symbolic link
error: man7/futex.7: does not exist in index
Patch failed at 0001 futex_waitv.2: new page
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Press any key to continue...
Hm, I did recently set
$ git config diff.noprefix
true
I didn't expect this to affect format-patch diffs
(since it doesn't affect diffs shown by git add -p),
or, if it did, I expected the designated consumer of format-patch
diffs (am) to understand this. perhaps not;
maybe -p0 to git am?
A quick search yields
https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#eaa0323ec4eed441b37caf96e1b136529b298dbac
where you're in the thread and the maintainer says "queued" for a patch
that would ignore noprefix for format-patch for this reason precisely.
But clearly not, since my patches were with noprefix=true and came out -p0.
See 15108de2 (Merge branch 'jk/format-patch-ignore-noprefix',
2023-03-21).
An aside but `format.noprefix` is not a boolean like `diff.noprefix`.
It will be enabled with any value.
Is it standard to indicate this with the existing “If set,”, perhaps? Or
should it say “enabled with any value”?
(+Cc Peff)
format.noprefix::
If set, do not show any source or destination prefix in patches.
This is equivalent to the `diff.noprefix` option used by `git
diff` (but which is not respected by `format-patch`). Note that
by setting this, the receiver of any patches you generate will
have to apply them using the `-p0` option.
Hi Kristoffer, наб,
On 2026-02-10T16:54:02+0100, Kristoffer Haugsbakk wrote:
On Tue, Feb 10, 2026, at 15:30, Alejandro Colomar wrote:
quoted
Hi!
On 2026-02-10T15:17:55+0100, наб wrote:
quoted
Hi!
On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
quoted
On 2026-02-07T23:00:49+0100, наб wrote:
quoted
Signed-off-by: Ahelenia Ziemiańska <redacted>
For some reason, the patch doesn't want to apply. I don't see anything
obviously wrong, so it may be an issue in my side?
Applying: futex_waitv.2: new page
error: affected file 'man2/futex_waitv.2' is beyond a symbolic link
error: man7/futex.7: does not exist in index
Patch failed at 0001 futex_waitv.2: new page
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Press any key to continue...
Hm, I did recently set
$ git config diff.noprefix
true
I didn't expect this to affect format-patch diffs
(since it doesn't affect diffs shown by git add -p),
or, if it did, I expected the designated consumer of format-patch
diffs (am) to understand this. perhaps not;
maybe -p0 to git am?
A quick search yields
https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#eaa0323ec4eed441b37caf96e1b136529b298dbac
where you're in the thread and the maintainer says "queued" for a patch
that would ignore noprefix for format-patch for this reason precisely.
But clearly not, since my patches were with noprefix=true and came out -p0.
See 15108de2 (Merge branch 'jk/format-patch-ignore-noprefix',
2023-03-21).
Ahhh, it seems that the OP is using a too-old version of git. I saw at
the bottom of the patch 2.39.5. But the fix was part of 2.41.0.
$ git describe --contains ab89575387c02ea024163256826ad1c6dd2e4247
v2.41.0-rc0~141^2
This seems reasonable. наб, would you mind not using that flag unless
you use a recent-enough git(1) (I suspect you're on an old Debian)? :)
alx@devuan:~/src/linux/git/main$ git show v2.41.0 | grep ^Date
Date: 2023-06-01 15:28:43 +0900
Date: 2023-06-01 15:28:26 +0900
alx@devuan:~/src/linux/git/main$ git show v2.39.5 | grep ^Date
Date: 2024-05-30 17:22:58 -0700
Date: 2024-05-30 16:52:52 -0700
alx@devuan:~/src/linux/git/main$ git show v2.39.0 | grep ^Date
Date: 2022-12-12 09:59:23 +0900
Date: 2022-12-12 09:59:08 +0900
Have a lovely night!
Alex
An aside but `format.noprefix` is not a boolean like `diff.noprefix`.
It will be enabled with any value.
Is it standard to indicate this with the existing “If set,”, perhaps? Or
should it say “enabled with any value”?
(+Cc Peff)
format.noprefix::
If set, do not show any source or destination prefix in patches.
This is equivalent to the `diff.noprefix` option used by `git
diff` (but which is not respected by `format-patch`). Note that
by setting this, the receiver of any patches you generate will
have to apply them using the `-p0` option.
From: Jeff King <hidden> Date: 2026-02-11 07:36:03
On Tue, Feb 10, 2026 at 04:54:02PM +0100, Kristoffer Haugsbakk wrote:
An aside but `format.noprefix` is not a boolean like `diff.noprefix`.
It will be enabled with any value.
Huh, that's weird. Indeed, the code is:
if (!strcmp(var, "format.noprefix")) {
format_no_prefix = 1;
return 0;
}
which seems just wrong. I cannot think of any other case where the
_existence_ of a config variable determines the outcome, rather than the
assigned value. So I would be inclined to call this a bug and switch it
to use git_config_bool().
Technically that is not backwards-compatible, but I really think the
existing behavior is just a bug. It was not something intended and is
contrary to how the rest of Git works. Presumably nobody noticed because
why in the world would you set it to false in the first place?
Is it standard to indicate this with the existing “If set,”, perhaps? Or
should it say “enabled with any value”?
(+Cc Peff)
format.noprefix::
If set, do not show any source or destination prefix in patches.
This is equivalent to the `diff.noprefix` option used by `git
diff` (but which is not respected by `format-patch`). Note that
by setting this, the receiver of any patches you generate will
have to apply them using the `-p0` option.
We usually use "if set" in the config documentation to refer to options
being set to the true value. So I think the documentation text is OK and
would match the code, once fixed.
Kristoffer, do you want to produce a patch to fix the code? I feel like
finding it was 99% of the work. ;)
-Peff