On Wed, Jun 18, 2025 at 02:29:49PM +0100, Simon McVittie wrote:
> The typical Github/Gitlab workflow encourages having a separation between
> two categories of branches:
>
> - stable, "public", safe to reference and will not be force-pushed
> (for example "main" or "0.2.x" or "debian/latest")
>
> - work-in-progress, unstable, expected to be force-pushed, only exist as a
> collaboration point
>
> In the email-based Linux-kernel workflow, if I understand correctly, the
> convention is that only the first category ever get pushed anywhere public,
> and the second category exist only on your laptop (because they're sent to
> other developers as patches, rather than as a complete branch).
It varies; for large patch sets, the developer submitting the change
will publish it some place public. This is why on git.kernel.org
you'll see trees such as kernel/git/djwong/e2fsprogs, for example.
(Darrick had some 50+ commits to fuse2fs split across 5 or 6 patch
series, and in that case, the first few series were bug fixes, and the
last few patch series were massive changes for better performance
using iomap and large folios, and will wait until I open up the tree
for the next major release of e2fsprogs. During the interim Darrick
has been rebasing his tree as I finalize e2fsprogs 1.47.3.)
There are also some subsystem maintainers that will take something
that isn't quite _final_ onto their subsystem branch, and then they
will replace the patch series by rewinding the branch when there are
updates. That way the not-yet-final, but mostly ready patch set can
get testing exposure on linux-next. Christian Brauner has been known
to do this with the VFS.git tree, for example. This is great, because
those of us doing CI testing specific to xfs, ext4, btrfs, and
bcachefs, can test upcoming changes while the patch series is still
being worked upon. Basically, there is no one single way things get
done.
People will also tag their code submissions with tags in the subject
line, e.g. "[PATCH RFC]", or "[PATCH WIP]" or even "[PATCH DO NOT SUBMIT]".
If there are a huge number of pending changes, I will create a branch
of the form "<initials>/<branch>" and merge them into a "pu" branch
("proposed updates") which is a convention used by Junio in the git
repo (which also uses a e-mail based workflow, BTW --- and I haven't
noticed a shortage of new contributors to git, *either*).
I generally only will use the pu branch workflow when when are a large
number of outstanding patch series, some of which might have merge
conflicts, so that contributors know about the potential issues, can
let me know if I screwed up the merge resolution, and otherwise
collectively help with the air traffic control as we try to
successfully land those patch series.
(Good luck doing this with the Forge Merge Request paradigm!)
Cheers,
- Ted
