Re: [PATCH v4] send-email: Add simple email aliases format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]