Comment by palata | Hacker News Reader

Comment by palata | Hacker News Reader

Parent Full thread

Of course, at some point you probably want an authoritative main branch from which you make your releases (though there can be forks, too).

I meant more in terms of development. The way git is used most of the time is by having a main branch on GitHub, that contributors clone, work on a feature branch, then make a PR, have QA test it, and merge it. If that cycle is too slow, many times the devs will start complaining because they are "stuck until the branch is merged". Because the assumption is that everybody branches from the main branch.

But git was designed around the email workflow. Instead of a PR, you make a patch (or a group of patches), that you can share with others. For instance, you can share a patch with a colleague from your team, who will review it and incorporate it in their branch before it gets merged into main. That way they are testing it by using it. At some point your changes get merged into the main branch, and your coworkers can just apply their patches on top of it.

We can imagine a workflow with a hierarchy of maintainers: devs at the lower level send patches to their supervisor, who after a while sends them up to their supervisor, up to the main branch.

PRs flatten all that. Devs typically never learn how to deal with patches, and the review process ends up being "rebase on main, run the CI, then I'll skim through your code, I'll complain about some variable names and I'll approve without even pulling your code" (I'm exaggerating a bit, of course).

I think there is a lot of value in learning the git email workflow.

This post (not mine) is about this: https://web.archive.org/web/20170823054920/https://dpc.pw/bl...

And of course SourceHut (https://sourcehut.org/, not mine) is a great forge built around the email workflow.

> I meant more in terms of development. The way git is used most of the time is by having a main branch on GitHub, that contributors clone, work on a feature branch, then make a PR, have QA test it, and merge it. If that cycle is too slow, many times the devs will start complaining because they are "stuck until the branch is merged". Because the assumption is that everybody branches from the main branch.

That my VCS is distributed is a goes-without-saying at this point. Nothing else is good enough. But a completely different dimension is integration. And I want to be as integrated as possible. And for everyone else as well. I don’t want three different cliques working on disparate things. And I warn against such things at work as well (i.e., hey let’s make a branch for this project which 3/9 of us is going to work on for a month...).

> But git was designed around the email workflow. Instead of a PR, you make a patch (or a group of patches), that you can share with others. For instance, you can share a patch with a colleague from your team, who will review it and incorporate it in their branch before it gets merged into main. That way they are testing it by using it. At some point your changes get merged into the main branch, and your coworkers can just apply their patches on top of it.

This certainly has merit. I mean peer-to-peer integration branching. But you can do the same with forges and branches. In fact it’s more difficult to keep track of patches via email, i.e. what comes from where, have I included this already, etc. Just consider the conversations that seem to keep coming up on how to deal with identifying patches.[1]

> We can imagine a workflow with a hierarchy of maintainers: devs at the lower level send patches to their supervisor, who after a while sends them up to their supervisor, up to the main branch.

I mean you should expect Whatever The Law about the org hierarchy being reflected in processes, not vice versa. Apparently there isn’t a process for this command hierarchy to be reflected in.

> PRs flatten all that. Devs typically never learn how to deal with patches, and the review process ends up being "rebase on main, run the CI, then I'll skim through your code, I'll complain about some variable names and I'll approve without even pulling your code" (I'm exaggerating a bit, of course).

Patches or not doesn’t really change that. If one single email thread becomes the focal point of a month-long development “PR” then that’s the same thing.

But yes. Getting out of that dang “fork” mindset is good. You can be more loosey goosey via email since you just inline your suggestions as patches (either with a commit message or without).

[1] https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8...

Reply on news.ycombinator.com