On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano <gits...@pobox.com> wrote: > Allen Hubbe <alle...@gmail.com> writes: > >> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gits...@pobox.com> 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
I imagine that's what most people would do, faced with the same issue. I did initially go look at those formats. Since I didn't really prefer any of them, I approached solving the problem in a different way. > > - 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. That "for example" is it. Why should I have to type "alias" before each alias in the file? It's not in any way hard to do - it just serves no purpose other than to make the parser happy. Perhaps the keyword does serve a purpose in mutt, but for me it is pointless to type that. > >> 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. 1 vote for useful. I realize this is self serving, but I hoped sharing it would benefit others. > >> 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. (3) good citizenship in open source to share one's changes to the code. > > 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. > I get that, in the general case, and especially for large features that affect a lot of the user base. How worried are you in this case, about (2), for such a small amount of code that now has a more extensive unit test case and documentation than any of the other options? -- 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
