Ask HN: Distributed development with Git patches but not email?
1 comments
When I’ve switched between my desktop and my laptop, I sometimes realize that I want some unpushed work-in-progress that’s still on the other machine. Then I often do:
ssh other-machine git -C path/to/repo format-patch --stdout main.. | git am
ssh other-machine git -C path/to/repo diff | git apply
The most typical public development with Git seems to be with forges and the pull request model:[1] make a fork, make your own branch, do the changes, push the code to your fork, and then open a PR.
The “original” way is to use email (`git send-mail`): make your changes into patches and start an email thread somewhere.
And when people argue about which one is better it’s often about how using pull requests is easier, how email is more distributed, how people don’t want to depend on GitHub/GitLab/etc., and things like that.
But I saw a comment[2] recently that made me think:
> Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to. The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories".
This is a good point: Git forges make one-off forks easy, but before we had GitHub and the rest it would have seemed excessive to ask a casual contributor to make a publicly-available copy of the repository with their proposed changes on top. But sending patch files is conceptually simpler (in a way).
Apropos this I had a thought: why aren’t there more ways to share patches than with email? Maybe there are, but I’ve googled around a bit and haven’t found much yet.
A Git-style patch (which includes the commit metadata like the commit message) is just a little snippet. Why don’t people casually share small modifications like that in chat applications, on forums, and other such avenues? Well maybe they do, but I haven’t really seen it so far.
I wanted to send some commits to a project once which used a mailing list. It was just a documentation fix, so I ended up spending 98% of that time on making a setup in Emacs where I could send out inline patches without them getting mangled (whitespace and so on) in transit. So I get the arguments against sending patches via email.
But it’s simple to paste a snippet from your clipboard into Git (using `git apply`). And we copy-paste snippets all day long. So using patch files/snippets isn’t inherently difficult once you know what base to apply them to.
I’ve also had the thought when reviewing PRs that I would sometimes just like to propose a patch instead of making my own branch, making a commit, pushing it, and then make a PR on top of the PR that I’m reviewing.
Have you seen this kind of non-email patch sharing in the wild?
[1]: Or just “merge request” if all developers have access to the same repository.
[2]: https://news.ycombinator.com/item?id=32223087