hehe... OK, lets try this one more time...
On Wed, Apr 8, 2009 at 2:12 PM, Florian Klaempfl <flor...@freepascal.org> wrote:
>> In that case, all you would need is an editor that supports Unix line
>> endings and not try and convert them to crlf as you edit the file -
>
> Oh, maybe at the end I should switch to linux to use git ;) ?
Only if you want a descent OS, but I thought we were only talking
about descent editors. ;-)
> Windows uses #10#13 as newline marker, period. A program which cannot
> handle this well (and svn shows that it is perfectly possible) is simply
> crap and is not suitable for windows development.
And Linux uses #10 as newline marker, period. A program which cannot
handle this well (and git shows that it is perfectly possible) is
simply crap and is not suitable for Linux development.
So what's you point??? Git *does* handle it correctly - it's
perfectly possible.
My reading of the description of `crlf` in gitattributes(5) is:
==========================
`crlf`
^^^^^^
This attribute controls the line-ending convention.
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
==========================
Note the "without guessing" part. I got it slightly wrong before - by
default git treats all files as text. It only tries to auto detect
*binary* files. And if for some reason git does do a good job or you
are overly paranoid you can help git out. For example, if you want all
*.foo files to be treated as binary files you can have this line in
.gitattributes:
*.foo -crlf
This will mean all files with a .foo extension will not have carriage
return/line feed translations done. Simply add the .gitattributes into
the root directory of your project so it's a tracked file. Now
everybody using that project will also get the .gitattributes file.
>> 'eol-style' property in SubVersion. Git tries to auto detect text
>> files and ONLY applies the crlf conversion on those.
>
> And that's what sucks: *auto detection* :)
As i mentioned earlier, I got this slightly wrong. By default git
treats all files as text. It only tries to auto detect *binary* files.
>> should not contain any binary files other than images, and they work
>> correctly even with 'autocrlf=True'. And if a binary file is detected
>> incorrectly as a text file, you can tell git about it using
>> .gitattributes file.
>
> How can I prevent that I forget this?
By creating the .gitattributes file in the root of the project and
adding it to your project.
$ (create your .gitattributes file in root directory of project)
$ git add .gitattributes
$ git commit -m "added gitattributes file to project"
Which means the file is now part of the project. Anybody cloning the
project will now automatically get the .gitattributes file and have
all the correct settings that the project managers decided on. The
same thing is done with the '.gitignore' files in the fpGUI directory.
Cloning fpGUI, git will automatically ignore all *.lps;*.ppu;*.o;*.a
files when you commit or do a status check. The user doesn't need to
do anything on their side.
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-other
