TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Distributed development with Git patches but not email?

1 点作者 nativecoinc大约 2 年前
Have you heard of sharing patches produced by Git but through some other medium than email?<p>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.<p>The “original” way is to use email (`git send-mail`): make your changes into patches and start an email thread somewhere.<p>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&#x2F;GitLab&#x2F;etc., and things like that.<p>But I saw a comment[2] recently that made me think:<p>&gt; Git was not designed for remote fetching from every menial contributor. Nothing was—it didn&#x27;t make sense to. The idea with git-pull is that it&#x27;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 &quot;infrastructure to let others pull directly from their repositories&quot;.<p>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).<p>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.<p>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.<p>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 <i>get</i> the arguments against sending patches via email.<p>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&#x2F;snippets isn’t <i>inherently</i> difficult once you know what base to apply them to.<p>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.<p>Have you seen this kind of non-email patch sharing in the wild?<p>[1]: Or just “merge request” if all developers have access to the same repository.<p>[2]: https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32223087

1 comment

Hackbraten大约 2 年前
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:<p><pre><code> ssh other-machine git -C path&#x2F;to&#x2F;repo format-patch --stdout main.. | git am </code></pre> Alternatively, if stuff is uncommitted and unstaged:<p><pre><code> ssh other-machine git -C path&#x2F;to&#x2F;repo diff | git apply</code></pre>