Re: What's cooking in git.git (Oct 2022, #06; Wed, 19)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2022, 15:35 UTC
Message-ID: <xmqqr0z2mrsl.fsf@gitster.g>
In-Reply-To: <e70b19de-d990-9844-6a0c-994ceabd9102@iee.email>

Philip Oakley <philipoakley@iee.email> writes:

Show 19 quoted lines

> On 20/10/2022 02:34, Junio C Hamano wrote:
>> * po/glossary-around-traversal (2022-07-09) 3 commits
>>  - glossary: add reachability bitmap description
>>  - glossary: add commit graph description
>>  - glossary: add Object DataBase (ODB) abbreviation
>>
>>  The glossary entries for "commit-graph file" and "reachability
>>  bitmap" have been added.
>>
>>  Expecting a reroll.
>>  cf. <dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email>
>>  source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>
>>
> Hi Junio
>
> I'm close to re-submitting.
> Would you want the V2 to be rebased onto v2.38.1, or stay where it was
> dc8c8deaa6 (Prepare for 2.36.2, 2022-06-07).
> It's a clean merge so far.

Thanks.

I usually would prefer to see the topic not rebased, especially if a rerolled topic still merges cleanly, and especially when the original base chosen was an older maintenance track, not a commit near the then-current tip of 'master'. Being queued on top of then-current 'maint' (or older) is an indication that the topic can be taken as "fixes" to the older maintenance release(s). I'd hate to see something that used to be merge-able down to fix issues in older maintenance tracks suddenly become limited only to future releases [*]. It also makes it simpler to run "range-diff @{1}..." and "diff @{1}" (it is essential for the latter to have the same base) for sanity-checking the result of accepting a new round.

When the original base was not any of the maintenance tracks but was near the tip of then-current 'master', I still prefer to see the base kept unless there is a compelling reason to rebase. There is one exception to this, though. When the original is so old, its base can now be a descendant of some maintenance track, even if it was near the tip of then-current 'master' when the topic was queued. Such a topic is unlikely to be a "fix" and the value to keep it merge-able to older maintenance tracks is much lower. So for such a topic, I think a clean reroll on top of the last stable release would be OK, and may even be preferable.

[Footnote]

 * It is a different matter if I actually merge them down to future
   maintenance releases, but for some distros that care to support
   older maintenance tracks, being able to merge those topics that
   are marked as "(merge X later to maint)" in the RelNotes would
   make their life easier than having to cherry-pick them.