Allen Hubbe <allenbh@xxxxxxxxx> writes: > On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Let me step back a bit. Earlier you said your aim is not to use an >> alias file you already have and use with the MUA/MTA, but to have a >> collection of aliases to use with git-send-email only. Is there a >> reason to add support for a new format (whether it is compatible to >> or subset of postfix/sendmail format, or a totally new one) for that >> goal? What makes the existing formats unsuitable? > > It's just a matter of personal preference what is suitable or not, for > me, in my environment, etc. Is there a reason I should use the alias > format of some email client, if I don't use that email client? I do not think "should" is a good word in the context of that sentence, as nobody is forcing you to choose one of the existing formats. But one reason you might want to do so would be because git-send-email already knows about it. It is a different matter if you already use an email client that supports your new format and you are trying to reuse an alias file with that email client. But I got an impression that was not the case, so the choice seemed to me between - learning and using one of existing 5; and - inventing, adding support for, and using a new one. That felt to me was a choice that is clearly not in favor of the latter, and I was wondering if there were other reasons to shift the balance. For example, "all of the existing formats are klunky and difficult to write" might be why "learning and using one of existing 5" is not a win, compared to "inventing, ading support for, and using a new one". I do not know if that is the case, so I wanted to hear the reason why. > I'm not trying to force anything on anyone else by offering this, just > another option that might be suitable for someone else, in their > environment, as it is in mine. People who don't like it can choose a > different option. People who don't like any of the options can write > their own like I did, or is that not allowed for some reason? We prefer not to carry dead code---when we add things, we would want to make sure it will be widely useful so that other people benefit. > I've already shown that I am willing to change the name, write the > documentation, write the tests, modify the syntax, and so on. I've > done the work, from +6 lines to +57 lines, as requested. I'm not > looking forward to v5, v6... v10 of what was a really really simple > patch. If you don't like it, please don't string me along. This is > not my job. Yeah, I know. A trade off from contributor's side is between (1) handing the maintenance to the upstream, so that a feature will stay available with minimum fuss in the future, or (2) having to carry one's own enhancement forward every time one updates from the upstream. On the other hand, a trade off from project's side is between (1) rejecting a half-way finished ware and hurting feelings of people and (2) accepting a half-way finished ware and having to spend engineering effort (e.g. making sure it fits to the rest of the system without adding dead weight) to polish it to the end. -- 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