31 ms·

The advantages of an email-driven Git workflow

• Areading314 8y ago
  This might work for slow moving teams with a few contributors, but I can't imagine using this in the way I've seen github used on projects with many contributors... Email just doesn't scale as well
  • hyperpape 8y ago
    Since he mentions Linux as the primary example of a project that uses email, I think this particular criticism needs some refinement.
    • Areading314 8y ago
      I'm sure plenty of Linux maintainers would much prefer using github if they could...
      • hyperpape 8y ago
        Maybe! I'm also a skeptic—see my other comment. But just saying "it can't work" is untenable.
      • Areading314 8y ago
        Here is an interesting post about the Linux project and why they don't use GitHub https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne...
    • craftyguy 8y ago
      Mesa is another large project using email for patch submission and review.
    • kccqzy 8y ago
      > Using email for git scales extremely well. The canonical project, of course, is the Linux kernel. A change is made to the Linux kernel an average of 7 times per hour, constantly. Tell that to any big team in a big company or even a medium-sized company using a monorepo. The Linux project has a very high bar for entry and it's not an example of a busy repo.
      • Sir_Cmpwn 8y ago
        Linux upstream gets 7 commits per hour, but the Linux project is divided into subsystems which are run like independent projects that periodically push their work upstream. The volume of activity that Linux receives is very high. Can you back up your statements with evidence? I have no reason to believe that email wouldn't work in a large monorepo-like setting. The less-than-10-in-total companies which have crazy Google-tier monorepos may run into issues with this (honestly, though, I doubt it), but they are not the norm.
    • progval 8y ago
      Linux is kind of special, only experienced developers contribute to it because working on a kernel is hard. Most projects are more accessible to beginners, and GitHub makes it much easier for them to do their first contribution to an open source project.
  • wskinner 8y ago
    Can you explain why email doesn’t scale? Do you mean the protocols, the clients, the servers, or something else?
    • Areading314 8y ago
      Having to sort through messages individually, not being able to browse code, no convenient links, no formatting, no branch visualizations, release notes being easily accessible, having to set up a bunch of fragile text based filters. It's just obviously a worse choice
      • rmurri 8y ago
        I don't think the intent is to do code review from email. The idea would be to send the merge request through email, which is then imported into your local git as a branch. Then you're able to do review/analysis/etc with whichever git tooling you prefer.
      • GuyPostington 8y ago
        Have you tried it to see if it's actually as bad as you think?
        • s73v3r_ 8y ago
          I guess the question would be, what compelling reason would there be to do so? To me, the article's advantages are kinda meh, and I much prefer the tools provided in code review packages.
      • sedachv 8y ago
        > Having to sort through messages individually Your email reader is supposed to help you read and reply to message threads. > not being able to browse code You browse code by doing a git clone/checkout, and then using your regular programming tools. > no convenient links Your email client should help you navigate and search message threads. Here is one of many that helps you do this: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html > no formatting This is what you editor is supposed to do. > no branch visualizations This is what tools like magit are supposed to do: https://magit.vc/ https://magit.vc/ > release notes being easily accessible They go in a text file in the repository. You open the text file with your editor. Your editor should also help you write release notes: https://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Ch... > having to set up a bunch of fragile text based filters. Why? I see arguments like yours about email and git a lot. Why do you think people disagree with you? You have to pay attention to what you are really saying. You are not listing advantages of web-based git interfaces. You are listing "disadvantages" of existing tools. And all of the "disadvantages" you list are really areas where you do not understand how to use Unix programming tools effectively. Getting off of webmail and onto a good text-based email client is one of the best things you can do as a computer user.
  • toopsss 8y ago
    If you knew one whit about what you’re talking about you’d feel pretty silly about this comment.
    • dang 8y ago
      You may be right, but this comment breaks the site guidelines by being uncivil and unsubstantive. That's not a good way to be right on HN. Better is to politely provide necessary corrective information, so then the rest of us can learn something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• matharmin 8y ago
  The article describes a lot about the workflow, but only two sentences about the advantages: > A very large body of email-related software exists and is equally reliable and well-understood. You can interact with email using only open source software and customize your workflow at every level of the stack - filtering, organizing, forwarding, replying, and so on; in any manner you choose. Using email software in general is well-understood, but using it for Git is much harder than using GitHub. Customizing the workflow is also something you probably shouldn't want to do unless you're really working with a massive project such as the Linux kernel.
  • hyperpape 8y ago
    Agreed. To begin with, telling everyone in your group to just stop using gmail/webmail is a non-starter, so you're going to end up having to lead people through setting up a second set of tools. And whatever the advantages of this workflow are, there are also disadvantages, or at least unanswered questions. How do you switch from inline diffs to side-by-side, toggle whitespace, integrate the results of a linter/static analyzer, etc? It's a good idea to build your collaboration tools on top of plain text/simple interfaces, but there are also a lot of needs that push you in the direction of a complex/powerful app. I was interested in the idea of alternative git tooling, but I don't think this article really delivers.
    • Sir_Cmpwn 8y ago
      I think these concerns are valid, and also addressed in the article towards the end. I believe the correct answer is not to throw these tools away like GitHub et al chooses to do, but to build upon them instead. Getting everyone to jump ship from webmail is hard, but instead of taking these tools away from email power-users I want to make web tools for e.g. interacting with mailing lists more powerful via my work on sr.ht.
      • hyperpape 8y ago
        > and also addressed in the article towards the end. Your perception might be that they're addressed, because you see your vision of how things should work. But to me, I can't see more than "trust me, I'm working on it". The value of that assurance depends on how well you see the limitations of the older workflows, not just their advantages. If you build it, that will assuage most worries, but talking about what you need in addition to the pure email workflow, and showing how it can be built would also help your case.
• jefurii 8y ago
  The author mentions this several times, but the Linux kernel project workflow is built around email, as described on LWN[0] and discussed here[1] and on Reddit[2]. [edited for format] [0] https://lwn.net/Articles/702177/ https://lwn.net/Articles/702177/ [1] https://news.ycombinator.com/item?id=15370620 https://news.ycombinator.com/item?id=15370620 [2] https://www.reddit.com/r/programming/comments/73gpys/why_linux_kernel_development_still_uses_email/ https://www.reddit.com/r/programming/comments/73gpys/why_lin...
  • ChrisSD 8y ago
    And git was specifically designed for that workflow.
    • wmf 8y ago
      You have to do a bunch of squashing and rebasing to produce clean patch series; I wonder if there could be a better UX for that.
      • pm215 8y ago
        I like 'stgit' for this -- it lets you manage a work-in-progress patch series as a stack of patches you can move around in, update, reorder and so on, which I find more natural than raw git rebases.
    • ChrisSD 8y ago
      Since this is oddly getting down votes for some reason, I'll quote wikipedia[0]: > Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development. [0] https://en.wikipedia.org/wiki/Git https://en.wikipedia.org/wiki/Git
      • paulddraper 8y ago
        Further, git provides utilities specifically meant to work with email workflows, e.g. git am.
• nunez 8y ago
  I'm a huge fan of Mutt and hate HTML email, but OP comes off as a kind-of curmudgeon. Reviewing pull requests semi-interactively on a browser or even though vim-diff in a single place has long beat email patch diffs for me. Also, Drew doesn't really delve into what makes email clients "bad." Email is so much more accessible than it used to be thanks to Outlook, Hotmail, Gmail and the like. HTML allows people and companies to be creative/abusive with their email. Plain text is quite restrictive.
  • zAy0LfpBZLC8mAC 8y ago
    > Plain text is quite restrictive. Which is a good thing, most of the time.
    • red75prime 8y ago
      Good for what? Security thru simplicity. It's easy to make copies in postapocalyptic world, where you have only a typewriter. You don't need fancy tools to view it. Anything else?
      • red75prime 8y ago
        The second part is here, because I recently read too many RFCs, which were devoid of examples, explanations and hyperlinks (right, plain text). I had no other ideas why is it that way.
  • cryptonector 8y ago
    Suppose there was a text-based format for mixing code/patch and commentary, and that this format lent itself well to processing in such ways as: - merge/collate commentary (from many emails, say) - display source with collapsed/collapsable commentary - track commentary accepted/rejected/extant/addressed status - track commentary metadata (who, when) Would that address your comment / needs? I mean, I use GUI/web-y code review tools because I find them much easier to use than email, but only because the problem they solve is: keeping track of all commentary. Collating comments (and status) from many emails is a time-consuming chore -- I hate it, and it's the only reason I don't want to do code review over email, but it's the only reason I have for not wanting to do code review over email. If we can solve this problem, then I'd be ecstatic to do code review over email.
• jwilk 8y ago
  If you send patches directly to the maintainer (rather than to a dedicated mailing list), you should put the project name in the subject, so that the maintainer doesn't have to guess which project this is about: $ git config format.subjectprefix 'PATCH foobar'
  • rwmj 8y ago
    It's be nice if this could be defaulted to something like the base name of the containing directory, so I could put this setting in ~/.gitconfig
    • Sir_Cmpwn 8y ago
      A simple wrapper script or alias around git-send-email could help you out here. The config option has the same effect as passing `--subject-prefix="..."`
  • cryptonector 8y ago
    Might as well add additional metadata in headers as well. Anything to make filtering easier.
• cryptonector 8y ago
  My comment on this is https://news.ycombinator.com/item?id=17443263 https://news.ycombinator.com/item?id=17443263 Tl;DR? My problem with code review over email is that keeping track of all commentary and metadata is difficult when reviewing over email. This seems like a solvable problem with a text format for interleaving source and commentary that is suitable for post-processing, particularly one that makes merging commentary easy, and preferably too that makes changing commentary metadata (e.g., comment accepted/deferred/rejected/addressed status) possible while retaining the ability to merge commentary.
• kazinator 8y ago
  > Popular email clients have caused terrible ideas like HTML email to proliferate That's a very backwards attitude that will turn away people. HTML in e-mails is a useful tool. I encourage it in the dev mailing lists that I operate. There is no conflict between HTML use and all the various dev-related use cases like posting patches or pull requests or whatever.
  • andreareina 8y ago
    Could you go into why you encourage HTML in the dev mailing lists you operate?
    • kazinator 8y ago
      Yes. I like the HTML formatting; it makes for more effective communication. You can use bulleted paragraphs; bold, italic, typewriter font. In a HTML message, you can have an indented code block which is not physically indented. When it is copied and pasted, it has no indent. Hyperlinks and images can be used in HTML messages, which is convenient. Color is possible: syntax colored code can be incorporated into an HTML e-mail. Also, I use an mailing list archiver called Lurker, which I customized such that it allows HTML messages to be incorporated into the archive. So poor archiving of HTML mails isn't any objection.
  • fyi1183 8y ago
    The main problem with HTML email is that it breaks interleaved responses ("bottom posting"). Bottom posting is so useful that even Outlook users reinvent it, badly of course, using different text colours etc. It's been decades now, why have none of the advocates of HTML emails fixed this really basic problem?
• na85 8y ago
  I seem to be in the minority of HN users that actually like Gmail and strongly dislike things like mutt or pine. Nothing else syncs to my phone in a manner that "just works" and doesn't require excessive fiddling, or using k9mail which appears to quite simply not work at all. So with that said, how does a person use git via email with the Gmail ui?
  • pm215 8y ago
    I use gmail for code review on a "send email patches" project (QEMU), and what I do is: * for sending patches, use git-send-email from the command line * for reading, use a greasemonkey script to make gmail use a fixed width font * when I need to apply a patchset locally I use the "patches" tool https://github.com/stefanha/patches https://github.com/stefanha/patches I also have a couple of gmail "canned responses" set up for things like "write my reviewed-by tag into my email reply". It's not fantastically ergonomic, but it's good enough that I haven't really felt the need to use something other than gmail web interface.
    • na85 8y ago
      Thanks!
    • stefan_ 8y ago
      I have the fixed width font, but how do you deal with the 78 columns limit? I guess you can have GMail auto-break it for you as it does when sending as text, but I think that ends up looking horrible over manually selected break points. But I'm really lacking some vertical bar to hint me where the limit is.
      • pm215 8y ago
        I have my gmail signature set to an ascii art 'ruler', so I know where column 75/80 are while I'm writing, and then I delete it when I'm done (and I do manual line breaks and if necessary manual rewrap of paragraphs)... Clunky but it works.
  • slrz 8y ago
• hagreet 8y ago
  Welcome to 2018. This is so sad I am exploding out both ends.
  • deleted 8y ago
    [deleted]
• ahnick 8y ago
  How would someone new to a project who might benefit from looking at historical patches AND the commentary surrounding them be able to access that information in an email-driven workflow? In a pull request model on GitHub, you can go in and view all the old comments from the pull request and get a good understanding of how/why a feature was implemented. Missing the contextual explanation of a feature and only being able to look at the commit history if you weren't on the mailing list to begin with seems like a big limitation to me. Or am I missing something?
  • Sir_Cmpwn 8y ago
    Mailing lists usually have public archives. Here are the archives for Linux and its various subsystems: http://vger.kernel.org/vger-lists.html http://vger.kernel.org/vger-lists.html
    • StillBored 8y ago
      Right but, then you have to sift through the dozens of unrelated comments, and if there are multiple versions of the patch frequently finding them and cross referencing the changes can be painful. You need look no further than the versionX->versionX+1 logs some of the kernel developers do to understand the problem. From one patch set to another the conversation around a piece of code gets lost, so much so that for long running patch series people will frequently show up and make the same request someone earlier in the series made because they missed the 20 emails talking about the pros/cons of doing something a certain way 6 months earlier.
      • deleted 8y ago
        [deleted]
    • imtringued 8y ago
      Using an email archive is almost equivalent to using a centralised service like github.
      • Sir_Cmpwn 8y ago
• sarah180 8y ago
  > Popular email clients have caused terrible ideas like HTML email to proliferate Regardless of whether it was a good idea or not, this ship sailed many years ago. In the 21st century, email is rendered in HTML, and nobody but a few engineers would even contemplate taking away the ability to render links, formatting and images in email. Personally, I would argue that email is on its way out. Personal communications have largely transitioned to things like SMS, Snapchat, Facebook Messenger, iMessage, Twitter, etc. Transactional email notices are increasingly being supplanted by mobile push notifications. Businesses are making heavy use of hybrid push-pull channel systems like Slack. IMO, the decentralized, federated nature of email was its downfall. It became a cesspool of spams, scams and unwanted notices. The research I've seen strongly suggests that it only takes a small amount of unwanted noise messages for people to go longer between reading email and reduce the amount of email they send. Of course these are problems that can be solved, but my prediction is that they will be solved by email's successors. Of course, technology predictions are hardly worth the bandwidth that delivers them, but that doesn't stop people from making them. ;-)
  • Sir_Cmpwn 8y ago
    >Regardless of whether it was a good idea or not, this ship sailed many years ago. In the 21st century, email is rendered in HTML, and nobody but a few engineers would even contemplate taking away the ability to render links, formatting and images in email. git is a tool for engineers. I could reiterate this comment for most of your points. We're not here to debate plaintext email for end-users, we're engineers talking about engineering tools.
    • progval 8y ago
      git is also a tool used by enthusiasts who want to make their first-time contribution to an open source project. Sadly, centralized web services like GitHub considerably lower the effort needed to do that first contribution.
    • Operyl 8y ago
      I have collaborators who are not necessarily engineers .. we’ve made it easy for them to use git, we really don’t need to be outcasting then because they aren’t an “engineer”.
• golergka 8y ago
  > It works well for > 15 million lines of code, thousands of developers: paid and unpaid, professional and amateurs alike. So it can benefit your projects as well. While I like git in general, this particular argument's logic is completely backwards. If something works well for 15 million lines of code and thousands of developers, then most likely it will be a gigantic overkill for your small project with a team of four, and overhead that goes unnoticed at Linux's scale will be crushing for you. At least, that's what I would think if I didn't know git first-hand. The fact that git turned out to be useful for small project is very atypical for a solution born out of needs of a huge one.
• deleted 8y ago
  [deleted]
• mankash666 8y ago
  Email workflows existed prior to the GitHub's of world. The latter won because of genuinely superior workflow