Re: [PATCH] fixup! propagate errno from failing read

[Junio C Hamano <gitster@pobox.com>]

"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Han-Wen Nienhuys <hanwen@google.com>
>
> This fixes a crash triggered by the BUG() statement.
>
> This can occur with symlinked .git/refs. To check availability,
> refs_verify_refname_available will run refs_read_raw_ref() on each prefix,
> leading to a read() from .git/refs (which is a directory).
>
> When handling the symlink case, it is probably more robust to re-issue the
> lstat() as a normal stat(), in which case, we would fall back to the directory
> case.
>
> For now, propagating errno from strbuf_read() is simpler and avoids the crash.
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> ---
>     fixup! propagate errno from failing read

Hmph, I do not see a commit with "propagate errno from failing read"
in its title anywhere in 'seen'.

I think the convention to assign errno to myerr in this codepath
originates in a0731250 (refs: explicitly return failure_errno from
parse_loose_ref_contents, 2021-07-20), and it forgot the part of the
code being fixed with this patch.  The commit being fixed is already
is in 'next' as part of the hn/refs-errno-cleanup topic.

Usually, a flaw in a topic that is already in 'next' is corrected by
a follow-up patch, but then they won't say "fixup!" (none of our
bugfix patches do).  But a post-release is a special time, as we
will soon be rewinding 'next', restarting it from the latest release
and we have a choice to tentatively eject a topic, fix it up or
even replace it, before merging the corrected topic to 'next'.

Do you mean that you want me to squash this change into that commit
before the topic graduates to 'master' during the new development
cycle?  If so please be a bit more explicit next time.  Using the
title of the commit after "fixup!" would be a good starting point.

Thanks.