On Tue, Aug 16, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote: > > I think you can squash in: > > > > diff --git a/run-command.c b/run-command.c > [...] > > Good point. > > BTW in light of the discussion we are having elsewhere I just need to > point out that it was *dramatically* faster for me to edit run-command.c, > find "hooks/" and adjust the code manually than it would have been to save > the diff and apply it. > > That's because I do not have advanced tooling on top of email (and I also > could not handle mutt, so I am stuck with a not-really-scriptable email > client). > > Just sayin'. There's a flip side, too. It was faster for me to paste in the diff than it would have been to create a branch, push it to GitHub, and make a PR on your PR (and then later remember to deal with my PR and branch so as not to leave them hanging around cluttering up my fork). I'm definitely sympathetic to people with less exacting email clients, but I'm not convinced that the GitHub flow is that great if you don't do the review there in the first place (and even when you do, it's actually not that great for suggesting things in patch form). I wonder if public-inbox could have helped here. I think: mid=20160815125006.qdssqgd4rzjw4vi5@xxxxxxxxxxxxxxxxxxxxx curl http://public-inbox.org/git/$mid/raw | git apply would work, but the question remains of how you find the right message-id. You can generally pick it out of the MUA's message headers manually, though I think some MUAs even make seeing the extended headers hard. But that's going to be a similar problem with any solution that isn't your MUA: how do you feed the context of the discussion happening in one place to another tool. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html