Comment by noirscape | Hacker News Reader

Comment by noirscape | Hacker News Reader

I'm pretty sure this approach is somewhat similar to the mailing list git approach, where patches usually get submitted once ready and then changed depending on feedback as a wholly new submitted patch (as part of a broader conversation).

It'd be a useful thing to import without having to bring in the whole charade of using email and mailing lists (which most mail clients tend to be very unfavorable of in general nowadays) - there's real advantage to doing this in a web interface instead.

UX would probably be more difficult though. The current workflow of "submit branch, make PR, do changes on same branch, merge latest version through web interface" is a big part of the ease of the Github UX. Doing a merge outside of that just by pulling in the right remote branches has always been a crapshoot at best and a pain in the ass at worst. Not helped by the fact that Github's documentation on how to do it in git is obscure (intentional I'm sure; I know it's possible but the docs are scattered and all of it recommend just using their gh CLI tool at this point).

> UX would probably be more difficult though. The current workflow of "submit branch, make PR, do changes on same branch, merge latest version through web interface" is a big part of the ease of the Github UX.

That was my first thought, too. Though perhaps a simple solution could be having GitHub, on a push, check for a new branch that matches an existing branch from a PR plus “-v2” (or “-v3”, etc.) and automatically consider that a new changeset in the PR.

Or perhaps even easier is once you’ve “released” your changeset in the GitHub ui, any pushes to the branch implicitly duplicate it and put it into a new v2 branch instead. That would be a decent ui from the pushers point of view, though there’s an and asymmetry between what you push and what ends up in the repo that I’m not sure I like.

> It'd be a useful thing to import without having to bring in the whole charade of using email and mailing lists (which most mail clients tend to be very unfavorable of in general nowadays)

This is a misconception. git itself has commands (git-format-patch and git-send-email) that automate the creation of patches and sending changeset email threads to the mailing list. The only thing one needs to do is set the appropriate configuration settings in their git config (which is a one time operation like setting your name and email address).

The actual interaction on the mailing list (responding to those who review patches and changesets can be done in any email client of one's choosing (though it's helpful to use an email client that supports threading using the Message-Id, In-Reply-To and Reference headers rather than one that only handles conversation view style replies).

No, it is not a misconception. How do I apply a patch from gmail to a specific git repo on my computer? (I would genuinely like to know the answer, but it must not involve mutt, gnus, or dovecot!)

Copy the content of the email to your clipboard, type `git am` in your terminal, paste and C-d to complete.

OK thanks, that sounds fairly convenient for small patches. And I expect you'd say download the email for larger patches (as a sibling commenter suggests).

In the worst case you can copy paste a patch into a new local file in the repo and then apply it with git from there. I’ve had somebody slack me patches before and it is not a big lift.

Save the email to your local machine (in gmail, click the 3 dots and choose download message). Then run

    git am < saved_email_file.eml

Right, thanks! (And using clipboard and stdin sounds even more convenient for small patches as a sibling comment suggests.)

Copy-paste may not work depending on how the email client renders the email. For example, if the email client doesn't preserve prefixed whitespace, then the resulting patch may be corrupted or not apply. Saving the actual email to a file on disk would avoid that issue.

Many local mail clients also just let you pipe the message into a command; for example, in mutt, you could just type:

   |git am

once you have the message open.

You may have a skewed idea of “most” here.

Most people are using gmail, but when it comes to local clients, Outlook, Apple Mail and Thunderbird are by far the most common and as far as I know none of them support this without extra steps.

Reply on news.ycombinator.com