Hi Stefan, 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 humans. 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 calendar, etc. 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 "stable" format. They don't. > 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. Sorry. > > 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[1] ;) > [1] https://public-inbox.org/git/CA+55aFy2AEe7ew5Px=2Uit6hraGV9zFr=JZ57rSYXWMQ4nMjeg@xxxxxxxxxxxxxx/ 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. Ciao, Dscho -- 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