All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Jonathan Tan" <jonathantanmy@google.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Han-Wen Nienhuys" <hanwenn@gmail.com>
Subject: Re: [PATCH] fixup! propagate errno from failing read
Date: Wed, 18 Aug 2021 11:30:39 -0700	[thread overview]
Message-ID: <xmqqo89u61ww.fsf@gitster.g> (raw)
In-Reply-To: <CAFQ2z_Ni1bvj0Skgp_3p9htQfjn_M=3uF06pyZm_hkXgT_L61g@mail.gmail.com> (Han-Wen Nienhuys's message of "Wed, 18 Aug 2021 11:00:36 +0200")

Han-Wen Nienhuys <hanwen@google.com> writes:

>> 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.
>
> The problem fixed here affects anyone who uses git-repo (ie. does
> Android development) and runs "git-branch -m", which is a large group
> of people, so I think it should not be allowed to get into a release.

OK.  The problem already is in 'next' and we want to make sure it
won't graduate to 'master' for the next release as-is.  I agree with
that ;-)

> So it could be squashed into commit a0731250, or put on top of next as
> a separate commit (probably with 'fixup!' removed).

I'd try the former first and will fall back on the latter, then.

> Note that, even though commit a0731250 originates from a branch called
> "hn/XXX" and has me as Author, the BUG() call causing the crash was
> actually introduced by AEvar when he reworked the series.

Yup, I see his Sob after yours and it is quite understandable if a
new bug was introduced by his changes. It also would be
understandable if his change was only to add a call to BUG() in
order to assert that the original patch used myerr consistently, and
it uncovered a bug in the original version he took from you.

I do not care too much about how exactly the bug was introduced and
uncovered---it matters more that the end result has one fewer bug
thanks to the team effort.

  reply	other threads:[~2021-08-18 18:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 12:31 [PATCH] fixup! propagate errno from failing read Han-Wen Nienhuys via GitGitGadget
2021-08-17 16:14 ` Jonathan Tan
2021-08-18 22:19   ` Jonathan Nieder
2021-08-17 22:38 ` Junio C Hamano
2021-08-18  9:00   ` Han-Wen Nienhuys
2021-08-18 18:30     ` Junio C Hamano [this message]
2021-08-19  0:11       ` Junio C Hamano
2021-08-19  9:01       ` Han-Wen Nienhuys
2021-08-19  3:55 ` Jeff King
2021-08-19  5:01   ` [PATCH] t3200: refactor symlink test Carlo Marcelo Arenas Belón
2021-08-19  5:51     ` Eric Sunshine
2021-08-19  7:52     ` [PATCH v2] t3200: refactor symlink test from hn/refs-errno-cleanup Carlo Marcelo Arenas Belón
2021-08-19 20:26       ` Junio C Hamano
2021-08-19 20:26       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo89u61ww.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwen@google.com \
    --cc=hanwenn@gmail.com \
    --cc=jonathantanmy@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.