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

>
> "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.