I have had a bunch of trouble lately with git, which I suspect was the result of checking in a new file that had CRLF line endings instead of LF. I know that git is supposed to be able to deal with this, but my experience suggests it has a schizophrenic behavior regarding this.

My git checkin procedure is done with a script that prefaces it with:

tolf filename
detab filename

tolf ensures that the line endings are LF, and detab converts tabs to spaces. This canonicalizes all entries into git, and avoids all the ugly problems with CRLF.

Please ensure that you add these to your checkin workflow, or something equivalent. No, the .git settings are not sufficient.

(BTW, if someone wrote a D source code formatter, I'd love to add that to our checkin process!)
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

My git setup screams at me when I try to stage files with windows line endings.  If we put this in the gitconfig...

An alternative would be to have the autotester reject pulls that add \r\n's.

Relying on all contributors to do the setup themselves doesn't seem like it will work.

On Wed, Jan 16, 2013 at 8:47 AM, Walter Bright <walter@digitalmars.com>wrote:

> I have had a bunch of trouble lately with git, which I suspect was the result of checking in a new file that had CRLF line endings instead of LF. I know that git is supposed to be able to deal with this, but my experience suggests it has a schizophrenic behavior regarding this.
>
> My git checkin procedure is done with a script that prefaces it with:
>
> tolf filename
> detab filename
>
> tolf ensures that the line endings are LF, and detab converts tabs to spaces. This canonicalizes all entries into git, and avoids all the ugly problems with CRLF.
>
> Please ensure that you add these to your checkin workflow, or something equivalent. No, the .git settings are not sufficient.
>
> (BTW, if someone wrote a D source code formatter, I'd love to add that to
> our checkin process!)
> ______________________________**_________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-internals<http://lists.puremagic.com/mailman/listinfo/dmd-internals>
>

Yah, we should add a pre-commit hook. I found a script on the net. How do we load it into .git/hooks/ so everybody gets it?

Andrei

On 1/15/13 9:24 PM, Daniel Murphy wrote:
> My git setup screams at me when I try to stage files with windows line
> endings.  If we put this in the gitconfig...
>
> An alternative would be to have the autotester reject pulls that add \r\n's.
>
> Relying on all contributors to do the setup themselves doesn't seem like
> it will work.
>
> On Wed, Jan 16, 2013 at 8:47 AM, Walter Bright <walter@digitalmars.com
> <mailto:walter@digitalmars.com>> wrote:
>
>     I have had a bunch of trouble lately with git, which I suspect was
>     the result of checking in a new file that had CRLF line endings
>     instead of LF. I know that git is supposed to be able to deal with
>     this, but my experience suggests it has a schizophrenic behavior
>     regarding this.
>
>     My git checkin procedure is done with a script that prefaces it with:
>
>     tolf filename
>     detab filename
>
>     tolf ensures that the line endings are LF, and detab converts tabs
>     to spaces. This canonicalizes all entries into git, and avoids all
>     the ugly problems with CRLF.
>
>     Please ensure that you add these to your checkin workflow, or
>     something equivalent. No, the .git settings are not sufficient.
>
>     (BTW, if someone wrote a D source code formatter, I'd love to add
>     that to our checkin process!)
>     _________________________________________________
>     dmd-internals mailing list
>     dmd-internals@puremagic.com <mailto:dmd-internals@puremagic.com>
>     http://lists.puremagic.com/__mailman/listinfo/dmd-internals
>     <http://lists.puremagic.com/mailman/listinfo/dmd-internals>
>
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I also like the idea of the autotester rejecting any files with CRLF. Brad?

On 1/15/2013 6:48 PM, Andrei Alexandrescu wrote:
> Yah, we should add a pre-commit hook. I found a script on the net. How do we load it into .git/hooks/ so everybody gets it?
>
> Andrei
>
> On 1/15/13 9:24 PM, Daniel Murphy wrote:
>> My git setup screams at me when I try to stage files with windows line
>> endings.  If we put this in the gitconfig...
>>
>> An alternative would be to have the autotester reject pulls that add \r\n's.
>>
>> Relying on all contributors to do the setup themselves doesn't seem like
>> it will work.
>>
>> On Wed, Jan 16, 2013 at 8:47 AM, Walter Bright <walter@digitalmars.com
>> <mailto:walter@digitalmars.com>> wrote:
>>
>>     I have had a bunch of trouble lately with git, which I suspect was
>>     the result of checking in a new file that had CRLF line endings
>>     instead of LF. I know that git is supposed to be able to deal with
>>     this, but my experience suggests it has a schizophrenic behavior
>>     regarding this.
>>
>>     My git checkin procedure is done with a script that prefaces it with:
>>
>>     tolf filename
>>     detab filename
>>
>>     tolf ensures that the line endings are LF, and detab converts tabs
>>     to spaces. This canonicalizes all entries into git, and avoids all
>>     the ugly problems with CRLF.
>>
>>     Please ensure that you add these to your checkin workflow, or
>>     something equivalent. No, the .git settings are not sufficient.
>>
>>     (BTW, if someone wrote a D source code formatter, I'd love to add
>>     that to our checkin process!)
>>     _________________________________________________
>>     dmd-internals mailing list
>>     dmd-internals@puremagic.com <mailto:dmd-internals@puremagic.com>
>>     http://lists.puremagic.com/__mailman/listinfo/dmd-internals
>> <http://lists.puremagic.com/mailman/listinfo/dmd-internals>
>>
>>
>>
>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/15/13 10:14 PM, Walter Bright wrote:
> I also like the idea of the autotester rejecting any files with CRLF. Brad?

Before that. It's a pre-commit or post-receive matter. Brad? :o)

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Wed, Jan 16, 2013 at 4:19 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
> On 1/15/13 10:14 PM, Walter Bright wrote:
>>
>> I also like the idea of the autotester rejecting any files with CRLF. Brad?
>
>
> Before that. It's a pre-commit or post-receive matter. Brad? :o)

You cannot put arbitrary Git hooks into a repository that will be run on end users' machines out of the box.

(This would be a huge security hole in Git.)
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/15/2013 7:21 PM, Alex Rønne Petersen wrote:
> On Wed, Jan 16, 2013 at 4:19 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
>> On 1/15/13 10:14 PM, Walter Bright wrote:
>>>
>>> I also like the idea of the autotester rejecting any files with CRLF. Brad?
>>
>>
>> Before that. It's a pre-commit or post-receive matter. Brad? :o)
> 
> You cannot put arbitrary Git hooks into a repository that will be run on end users' machines out of the box.
> 
> (This would be a huge security hole in Git.)

Correct, and github has no mechanism for it either.  So, I'm happy to add this checking to the load balancer, but someone else build the hook and play with it and get it working w/in their own environment first .  There's no reason it shouldn't be put in developer repositories and catch the problem BEFORE they get committed locally.  The auto tester can be the second layer of defense.

Later,
Brad
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/15/13 10:31 PM, Brad Roberts wrote:
> Correct, and github has no mechanism for it either.  So, I'm happy to
> add this checking to the load balancer, but someone else build the
> hook and play with it and get it working w/in their own environment
> first .  There's no reason it shouldn't be put in developer
> repositories and catch the problem BEFORE they get committed locally.
> The auto tester can be the second layer of defense.

I tried real hard to make http://gergap.wordpress.com/2010/05/12/git-crlf-hook/ work, but for some reason I couldn't get the update hook to run at all - even when I inserted an "exit 1" on the first line.

My procedure: copy the file into .git/hooks/update, make some changes, commit, and push to my github repo. The update hook never runs.

I did get the pre-commit script to run, but I couldn't find a pre-commit hook for crlf on the net and I don't have the time to investigate writing one.


Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/15/2013 8:36 PM, Andrei Alexandrescu wrote:
> On 1/15/13 10:31 PM, Brad Roberts wrote:
>> Correct, and github has no mechanism for it either.  So, I'm happy to add this checking to the load balancer, but someone else build the hook and play with it and get it working w/in their own environment first .  There's no reason it shouldn't be put in developer repositories and catch the problem BEFORE they get committed locally. The auto tester can be the second layer of defense.
> 
> I tried real hard to make http://gergap.wordpress.com/2010/05/12/git-crlf-hook/ work, but for some reason I couldn't get the update hook to run at all - even when I inserted an "exit 1" on the first line.
> 
> My procedure: copy the file into .git/hooks/update, make some changes, commit, and push to my github repo. The update hook never runs.
> 
> I did get the pre-commit script to run, but I couldn't find a pre-commit hook for crlf on the net and I don't have the time to investigate writing one.
> 
> 
> Andrei

That's what I meant earlier when I said that github has not mechanism for it.. they do not support running hooks in repos.  I meant that developers should have them in their LOCAL repositories for when they commit before pushing changes to github.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/15/13 11:49 PM, Brad Roberts wrote:
> That's what I meant earlier when I said that github has not mechanism for it.. they do not support running hooks in
> repos.  I meant that developers should have them in their LOCAL repositories for when they commit before pushing changes
> to github.

I see. Then I can't play with it. Any chance I'd convince you to try it?

http://gergap.wordpress.com/2010/05/12/git-crlf-hook/


Thanks,

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals