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

Philip Oakley [off-list ref] writes:

On 20/10/2022 02:34, Junio C Hamano wrote:

quoted

* 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. [ref]
 source: [ref]

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.