Re: [PATCH v2] futex_waitv.2: new page

Re: [PATCH v2] futex_waitv.2: new page

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

Hi!

On 2026-02-10T15:17:55+0100, наб wrote:
> Hi!
> 
> On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
> > On 2026-02-07T23:00:49+0100, наб wrote:
> > > Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> > 
> > 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.

Oh, that bites again!

Junio, do you still have this queued?
<https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>


Have a lovely day!
Alex

> 
> Best,



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2] futex_waitv.2: new page

[Kristoffer Haugsbakk]

On Tue, Feb 10, 2026, at 15:30, Alejandro Colomar wrote:
> Hi!
>
> On 2026-02-10T15:17:55+0100, наб wrote:
>> Hi!
>>
>> On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
>> > On 2026-02-07T23:00:49+0100, наб wrote:
>> > > Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
>> >
>> > 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.
>
> Oh, that bites again!
>
> Junio, do you still have this queued?
> <https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>

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.

Re: [PATCH v2] futex_waitv.2: new page

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

Hi Kristoffer, наб,

On 2026-02-10T16:54:02+0100, Kristoffer Haugsbakk wrote:
> On Tue, Feb 10, 2026, at 15:30, Alejandro Colomar wrote:
> > Hi!
> >
> > On 2026-02-10T15:17:55+0100, наб wrote:
> >> Hi!
> >>
> >> On Mon, Feb 09, 2026 at 11:35:53PM +0100, Alejandro Colomar wrote:
> >> > On 2026-02-07T23:00:49+0100, наб wrote:
> >> > > Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> >> >
> >> > 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.
> >
> > Oh, that bites again!
> >
> > Junio, do you still have this queued?
> > <https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>
> 
> 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.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2] futex_waitv.2: new page

[Jeff King]

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

Re: [PATCH v2] futex_waitv.2: new page

[Kristoffer Haugsbakk]

On Wed, Feb 11, 2026, at 08:35, Jeff King wrote:
>>[snip]
>
> Kristoffer, do you want to produce a patch to fix the code? I feel like
> finding it was 99% of the work. ;)

Sure, I want to take a look at it. :)

Re: [PATCH v2] futex_waitv.2: new page

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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().

Very true.  It is surprising that nobody noticed it during the review.


> 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

Re: [PATCH v2] futex_waitv.2: new page

[Junio C Hamano]

Alejandro Colomar <alx@kernel.org> writes:

> Junio, do you still have this queued?
> <https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>

Still queued??  Not very likely.

It is a topic from almost 3 years ago, so it is either in an ancient
released version, or it was discarded long time ago for some issues.
Given that it is from Peff, it is very likely the former.

https://git.kernel.org/pub/scm/git/git.git/commit/?h=15108de2fa0&id=15108de2fa0cd8f002a0551d14c84505a853071c    

That's v2.41.0-rc0~141 if my "git describe --contains" is counting
correctly.

My secretary will bill you for 30 minutes of my time and for making
me miss a meeting with external folks with this ;-).

Re: [PATCH v2] futex_waitv.2: new page

[Kristoffer Haugsbakk]

On Tue, Feb 10, 2026, at 17:54, Junio C Hamano wrote:
> Alejandro Colomar <alx@kernel.org> writes:
>
>> Junio, do you still have this queued?
>> <https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>
>
> Still queued??  Not very likely.
>
> It is a topic from almost 3 years ago, so it is either in an ancient
> released version, or it was discarded long time ago for some issues.
> Given that it is from Peff, it is very likely the former.
>
> https://git.kernel.org/pub/scm/git/git.git/commit/?h=15108de2fa0&id=15108de2fa0cd8f002a0551d14c84505a853071c
>
>
> That's v2.41.0-rc0~141 if my "git describe --contains" is counting
> correctly.
>
> My secretary will bill you for 30 minutes of my time and for making
> me miss a meeting with external folks with this ;-).

The email with the patch[1] seems to say Git 2.39.5 in the signature line.

    @@ -107,6 +111,7 @@ .SH NOTES
     .SH SEE ALSO
     .BR clone (2),
     .BR futex (2),
    +.BR futex_waitv (2),
     .BR get_robust_list (2),
     .BR set_robust_list (2),
     .BR set_tid_address (2),
    --
    2.39.5

That topic is not in any 2.39.* release.

† 1: https://lore.kernel.org/all/se6hm5gnd7cyjsby5q6pctkrws5ecp5gpnfjuy3zh2shd2abyj@tarta.nabijaczleweli.xyz/

Re: [PATCH v2] futex_waitv.2: new page

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Hi Junio,

On 2026-02-10T08:54:13-0800, Junio C Hamano wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Junio, do you still have this queued?
> > <https://lore.kernel.org/git/xmqqy1o5op1i.fsf@gitster.g/t/#m6f42ff4f0cb2d6dd1d68f12a533d04c822b68a80>
> 
> Still queued??  Not very likely.
> 
> It is a topic from almost 3 years ago, so it is either in an ancient
> released version, or it was discarded long time ago for some issues.
> Given that it is from Peff, it is very likely the former.
> 
> https://git.kernel.org/pub/scm/git/git.git/commit/?h=15108de2fa0&id=15108de2fa0cd8f002a0551d14c84505a853071c    
> 
> That's v2.41.0-rc0~141 if my "git describe --contains" is counting
> correctly.
> 
> My secretary will bill you for 30 minutes of my time and for making
> me miss a meeting with external folks with this ;-).

Ohh, sorry!  :)

The problem seems to be still alive in some stable branch, probably in
oldstable distros.  I guess I'll have to deal every now and then with
those, depending on how many people discover diff.noprefix while still
using old versions.


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]