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

Chandra Pratap <chandrapratap3519@gmail.com> writes:

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.