[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 May 2013 22:58:19 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Unify internal form of mscash2 hashes?
On 28 May, 2013, at 22:02 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 05/28/2013 08:42 PM, magnum wrote:
>> On 28 May, 2013, at 20:06 , magnum <john.magnum@...hmail.com> wrote:
>>> On 28 May, 2013, at 18:01 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>>>> You might want to experiment with a pre-commit hook that automatically
>>>> removes trailing whitespace or spaces before tabs in a *non-public*
>>>> repo, and if it turns out to work without unwanted side effects, enable
>>>> that pre-comkmit hook in the public repo.
>>>
>>> I probably need to read up on this. I know about commit hooks but I have absolutely no idea how to set one up on the remote side, at GitHub.
>>
>> OK, so the correct term is server-side pre-commit hooks, and GitHub does not support them. This is very likely for the reason I described: You'd be running arbitrary code at their servers.
>
> So we should try to find a precommit hook which we can ask contributors
> to use in their local git repo?
> Then, if you push from your local repo to the public repo, you already
> cleaned possible whitespace issues when committing to your local repo?
We could just as well ask them to configure their editors to never save trailing space (and why not indent correctly while at it), or avoid hitting the space bar as some kind of weird therapy in the first place. They won't obey that either. And somewhere at the bottom line I'll rather accept some bad formatting than seeing users give up if we get too picky. Like anything else, it's a compromise.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
