5 ms·

How would that even work without merging all the relevant changes at some point? If I want to use some open source software, I don't want to connect to every si

How would that even work without merging all the relevant changes at some point? If I want to use some open source software, I don't want to connect to every single forked repository to see if they might have local changes that I could need. ... and then dealing with all sorts of merge conflicts.

palata 3y ago
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/blog/2017/08/youre-using-git-wrong/ https://web.archive.org/web/20170823054920/https://dpc.pw/bl... And of course SourceHut (https://sourcehut.org/ https://sourcehut.org/, not mine) is a great forge built around the email workflow.
- avgcorrection 3y ago
  > 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/bdbe9b7c1123f70c0b4325d778af1df8fea2bb1b.camel@that.guru/ https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8...
riddley 3y ago
I may be wrong, but I think when Torvalds created it, he envisioned an email based workflow using patch files. In his use case, he is the single source of truth who decides what gets merged.
- melagonster 3y ago
  I remember he mentioned this in speech. he can merge changes from trusted people, and everyone have a personal list of people they trust... so he doesn't need to check everything by himself, and if anything goes wrong, they always can go back to last version.
jayd16 3y ago
You don't look for them. If you're the project owner, they request that you pull. Instead of a website, it can be done with email. If you're simply using the software, you would pull the maintainer or whoever is hosting the main branch or what have you.

palata 3y ago

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/blog/2017/08/youre-using-git-wrong/ https://web.archive.org/web/20170823054920/https://dpc.pw/bl... And of course SourceHut (https://sourcehut.org/ https://sourcehut.org/, not mine) is a great forge built around the email workflow.

avgcorrection 3y ago
> 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/bdbe9b7c1123f70c0b4325d778af1df8fea2bb1b.camel@that.guru/ https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8...

riddley 3y ago

I may be wrong, but I think when Torvalds created it, he envisioned an email based workflow using patch files. In his use case, he is the single source of truth who decides what gets merged.

melagonster 3y ago
I remember he mentioned this in speech. he can merge changes from trusted people, and everyone have a personal list of people they trust... so he doesn't need to check everything by himself, and if anything goes wrong, they always can go back to last version.

jayd16 3y ago

You don't look for them. If you're the project owner, they request that you pull. Instead of a website, it can be done with email. If you're simply using the software, you would pull the maintainer or whoever is hosting the main branch or what have you.