Re: core.autocrlf considered half-assed

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

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> Nevertheless, I agree with you that if a similar situation happened by 
>> mistake and your project does want to enforce core.autocrlf, it would be 
>> nicer if there is an easy-to-use one-time clean-up procedure.  It hasn't 
>> been my itch, and I suspect it wasn't Linus's itch either.
>
> The problem is that the whole thing was not your itch, but your 
> implementation. You never used it, so you never caught the obvious flaws 
> in the design.
>
> Sorry to be so direct, but it seems that my more subtle attempts to 
> explain the situation failed.

No, being direct is good---it shows the thought behind what you say more
clearly.

Think what "your implementation" means in the open source setting.  It is
what you were given for free, you could try to improve upon it if you so
desire, and you should be thankful for it.  It also means that you know
the people to ask for help as it is "their" implementation and they are
probably more familiar with it than others.  If you happen to be in the
position where you can see shortcomings in the implementation better than
they do, that's good; they and you can complement what each is good at,
and make progress collectively.

What it does _not_ mean is that you can _demand_ anything out of them,
though.  An attempt to shaming them into doing something amounts to the
same thing.  Having seen the way you have behaved on the msysgit list and
its tracker for a while, I thought you understood all that.
--
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]