On Fri, 19 Aug 2016, Stefan Beller wrote:
> >> I see a choice of mail client as no different than a choice of text
> >> editor. Neither my mail client or text editor is heavily customized.
> >> The key feature I rely on from both tools is piping data to external
> >> commands.
> > There you go. That key feature seems to be unavailable in the most
> > wide-spread email client: Outlook. So by not restricting the choice
> > you should make it possible to use that mail client, too, right?
> Well I think this data piping is essential to any workflow.
Data piping can go through Git, with convenient commands.
> Even if were to abandon email completely and roll our own communications
> protocol, one of the first things added would be an API to "use your own
> text editor".
> In my case git-send-email works well for the sending direction without a
> lot of custom tooling (read: none apart from the initial configuration).
Sending those mails is but the tiny, first step of contributing patches.
You know as well as I do that many a times contributors have to work
through many iterations to get their work accepted.
So while send-email helps with one direction, everything after that is
hard, manual work.
> > We do not even have a section on Outlook in our SubmittingPatches.
> "You can write one? Pretty please?" would be the canonical answer. ;)
Sure. And my answer to that is: I cannot write it. Why? Because I cannot
get it the heck to work. Because Outlook supports writing mails, i.e.
messages from humans for humans. You can change the font, insert a nice
photo from your vacations, left-justify, right-justify, center the text.
You can do all kinds of nice things that you need to do when talking to
You can even paste a diff, for a human to read. Humans are very good at
not even seeing that there is no space at the beginning of the line.
Humans are also very good at understanding that those 8 spaces are the
same as the tab in the source code.
Outlook can also keep excellent track of who was Cc:ed, of mail threads,
filtering mails based on a plethora of criteria, integrating with a
So Outlook does really an excellent job.
What it does *not* to well is something mail was not designed for.
> Maybe we should invent a patch format that copes with broken whitespace?
Or maybe we do not even have to go that far, but maybe we can teach `git
apply` a mode where it is much smarter about whitespace changes and
wrapped text in the patch it receives?
That would probably go a long way further to making the patch submission
process we use more friendly to human beings.
It still would not make it easy to go from replies containing suggestions
how to improve the code to the corresponding file/revision.
> >> Users ought to be able to pick, choose, and replace tools as they
> >> wish as long as an interchange format remains stable and
> >> widely-supported.
> > Right. Let's talk about the interchange format called mails, for the
> > data called patches. Is it stable and widely-supported?
> It is stable as it has been around for years and you can choose whether
> you use git apply or the patch utility.
You seem to assume that mail clients have an easy time with this supposed
> It is widely supported as it is raw text so it can be used across
> different platforms. However it doesn't cope well with email, as email
> modifies text sometimes such as mangling white spaces.
I "mangle" whitespace all the time when I respond to mails. You will note
that I re-wrap quoted text to 76 columns/row.
So I am as guilty as any mail client of your charge.
> > Can users really pick and choose the tools they like most to send patches
> > to the Git project? Like, the Outlook client? Or the GMail client?
> Of course, see ;)
You speak in riddles. That link leads to Linus' mail talking about
committerdates and generation numbers.
It does not help me, not in the slightest, to send a patch via Outlook or
the web interface of GoogleMail without risking to get yelled at for
corrupting the patch.
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