Re: [GSoC][PATCH v3 0/6] t: port reftable/stack_test.c to the unit testing framework

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

Chandra Pratap <chandrapratap3519@gmail.com> writes:

> I generally make sure to rebase my patches on top of the latest
> master before sending them to the mailing list.

This is generally considered a bad practice.  You shouldn't rebase
unless there is a compelling reason (e.g., API you rely on
disappeared and you need to reimplement your change differently, you
rewrote some code based on an old version, but the code you touched
have been enhanced so you'd need to rewrite the new part).

On the other hand, you should realize that every topic first is
queued to 'seen' and only after it proves that it plays well with
other topics in flight, it is considered to advance to 'next'.  So
if you conflict with other topics that makes you conflict when
merged to either 'next' or 'seen', you'd be better off creating a
more suitable base than 'master' and then build on top of it.

An effective way to do so is to mimick how topics like

  https://lore.kernel.org/git/cover.1724308389.git.ps@pks.im/

are built.  This one says:

    This patch series continues to build on top of 25673b1c47 (The third
    batch, 2024-08-07) with Junio's ps/reftable-stack-compaction at
    f234df07f6 (reftable/stack: handle locked tables during auto-compaction,
    2024-08-08) merged into it.

in its cover letter, allowing anybody to reconstruct the base with

    $ git checkout -b ps/reftable-drop-generic 25673b1c47
    $ git merge f234df07f6

before running "git am" to apply the series on top.  Because it
_depends_ on ps/reftable-stack-compaction, the resulting topic
cannot be merged to anywhere without dragging the base topic with
it, so such a dependency needs to be already fairly stable (e.g.,
have been thoroughly reviewed and merged to 'next'), but then the
topic will have less chance to conflict when merged to 'next' and
'seen'.

Thanks.