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:

  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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to