Re: [PATCH v2] reftable: write correct max_update_index to header

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jan 24, 2025, 04:06 UTC
Message-ID: <CAOLa=ZSisRwmUyLHAP0e=8U0QjfFbDfXwd2mJXKjVywcmM56Tg@mail.gmail.com>
In-Reply-To: <xmqqbjvxs8me.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 26 quoted lines

> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> While this patch was merged to next, Dscho reported that it was flaky
>> on macos pipeline. On further investigation I found this was easily
>> reproducible when the leak sanitizer was turned on and the reftable
>> tests were run. The fix was simply to add the missing 0 initialization.
>
> If it is already _in_ 'next', please turn it into a relative patch
> on top of it, instead of replacing it.
>
> That will give you an opportunity to describe the breakage in the
> original version, which everybody missed until it hit 'next'.  And
> you can also credit the folks who reported the breakage, and
> describe the fix.
>
> The reason we do not revert out of 'next' lightly is because the
> changes we merge to 'next' are supposed to be reviewed well enough,
> which means that any bug we discover later is likely to have been
> caused by mistakes any of us may repeat in the future, and it is
> worth documenting in our history.
>
> It is quite a different review philosophy if you compare the rules
> we use for patches that haven't hit 'next'.  These uncooked patches
> may have mistrakes that reviewers can easily spot and get corrected,
> and these easy ones are not worth documenting as much.
>

Thanks Junio, I understand your reasoning here and it makes sense to me. Do you think it is worthwhile to also add something like this to our Documentation? I couldn't find anything there. I'll add a small patch to the bottom of this mail.

>> The patch is based on Maint f93ff170b9 (Git 2.48.1, 2025-01-13).
>
> Thanks.

-- >8 --

Subject: [PATCH] doc: add guideline to tackle bugs in `next`

When fixing a bug in a topic already merged into `next`, there are no strict guidelines to follow. While topics in `seen` can be reverted, topics in `next` have undergone thorough review. Documenting fixes for such topics is valuable, as it helps to clarify the issue and contributes to preventing similar problems in the future.

Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
---
 Documentation/SubmittingPatches | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 958e3cc3d5..72454acf21 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -115,6 +115,13 @@ latest HEAD commit of `maint` or `master` based
on the following cases:
   new API features on the cutting edge that recently appeared in
   `master` but were not available in the released version).

+* If you're fixing a bug in a topic that's already been merged into
+  `next`, it's preferable to create a patch relative to that topic.
+  This approach allows you to describe the issue in the original version
+  that went unnoticed until it reached next. Additionally, it provides
+  an opportunity to credit those who reported the issue and document
+  the details of the fix.
+
 * Otherwise (such as if you are adding new features) use `master`.

-- 
2.47.0