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

[Junio C Hamano <gitster@pobox.com>]

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