Philip Oakley <philipoakley@iee.email> writes:
> 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@xxxxxxxxx>
>>
> 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.
