Chandra Pratap <chandrapratap3519@xxxxxxxxx> 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@xxxxxx/ 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.
