It was not my intend to start this discussion again with my initial email. I rather wanted to point out how I make progress in doing my own tooling. I mean if email works well for Junio (both as a maintainer as well as a contributor) and Jeff as a contributor, then I can adapt my workflow to that, because these two have brought in 8300 of 33000 non merge patches. (i.e. they had 25% of the patches over the life time of the project and are with the project longer than others IIUC). So why would I demand they change their style just to accommodate one newcomer like me? > >> 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. 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). > > We do not even have a section on Outlook in our SubmittingPatches. "You can write one? Pretty please?" would be the canonical answer. ;) > > Okay, if not the most popular mail client, then web mail? Nope, nope, > nope. No piping *at all* to external commands from there. > > So you basically slam the door shut on the vast majority of email users. > > That is not leaving much choice to the users in my book. > >> OTOH, today, I see people using git aliases all the time which >> look more like ASM instructions than user commands. > > I see this as a completely different beast. Aliases help users accelerate > their personal workflow. Whereas anybody who is already willing to > contribute to Git *must* go through that non-personal workflow we impose: > paste the diff in a very specific format into the mail, and don't you dare > use a mail client that mangles whitespace (which is, like, pretty much > every single popular mail client out there). Maybe we should invent a patch format that copes with broken whitespace? (git-format-patch --allow-broken-whitespace), e.g. replace a tab by "-_______" (not exactly 8 chars, but stopping at the columns 8, 16, 24 etc) git am/apply would need to know about the unbreaking the white space, too. > > So *allowing* users to configure their own aliases, and *forcing* them to > figure out how to transport patches through a medium hostile to patches, > is pretty much two diametrically opposed things. I think the point was that people carelessly expose their aliases in e.g. their blogs. (e.g. "to do <foo> you just need to git a <file> &&git ci && git rr", which leaves others just guessing? It certainly feels similar to not knowing how to configure your email client?) > >> 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. 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. > > 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/ Thanks, Stefan -- 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