On Tue, Jun 21, 2011 at 11:56, Vincent Torri <vto...@univ-evry.fr> wrote:
>
>
> On Tue, 21 Jun 2011, Thomas Gstädtner wrote:
>
>> On Sun, Jun 19, 2011 at 12:50, Albin Tonnerre <albin.tonne...@gmail.com>
>> wrote:
>>>
>>> On Sun, 19 Jun 2011 12:38 +0200, Vincent Torri wrote :
>>>>
>>>> Hey
>>>>
>>>> another idea about trailing whitespaces : what about adding a rule in
>>>> the
>>>> toplevel Makefile.am, named for example remove-ws, that call find with a
>>>> sed expression.
>>>>
>>>> I'll add it to Evil and test it a bit, and if nobody complains, i'll add
>>>> it to the EFL + e.
>>>
>>> While it is nice to get rid of trailing whitespaces, I think that
>>> actively
>>> removing them periodically does more harm than good. In particular, it
>>> adds a
>>> lot of noise in the history and makes it harder to compare different
>>> revisions.
>>>
>>> If we indeed want to get rid of them, I'd be much happier if the SVN
>>> server
>>> simply rejected commits containing them (the same holds true for
>>> formatting -
>>> it's much better to ask people to submit properly formatted patches
>>> rather than
>>> going on a reformatting spree every now and then)
>>>
>>> Cheers,
>>> --
>>> Albin Tonnerre
>>>
>>
>> I think putting this in a Makefile is a bad idea.
>> Alternative: how about using a pre-commit hook in SVN that either
>> removes whitespaces right away and sends a SPANK SPANK SPANK mail to
>> the evil dev who did it, or just rejects the patch as Albin suggested.
>> The first way is more proactive and should keep the commit/history
>> clean.
>
> then, you will have huge chances to have conflicts if you want to update a
> file that you changed in your repo and that has been modified in your back
> by that prehook, right ?
>
> Vincent Torri

That is true, but the "Don't do that, nasty programmer. SPANK SPANK
SPANK" mail tells you that the hook triggered and also it hurts the
programmer who did produce the trailing whitespaces. People learn best
when it hurts :P
It certainly is a rather harsh method to enforce this policy but it
certainly would keep this out.
(Of course pre-commit hooks always hurt, that's what they are for and
that's why they should be used really sparsely).
Also people having to clean their personal repos seems to be more
desirable than having trivial commits to remove that stuff in the
public history.

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to