[Fusionforge-general] .gitattributes set by Subgit ?

Christian Bayle gforge at free.fr
Fri Oct 19 22:17:57 CEST 2012


Hi,

maybe this is kind of requirement for subgit, if svn don't have such 
behaviour

As EOL is defined as : The End of Line (EOL) character (0x0D0A, \r\n)
I would read this as you did, that CR/LF normalization is not applied on 
checkin

But I found this :

http://stackoverflow.com/questions/11884394/how-do-i-avoid-git-svn-and-svn-crlf-problems-such-as-this-one

git attribute is '!eol' (that would mean get EOL setting from |core.eol| 
of .git/config).

and there is some explanation on how to solve crlf problems with subgit
too late for me to concentrate on understanding

Christian


On 19/10/2012 17:18, Olivier Berger wrote:
> Hi.
>
> I'm struggling with CR/LF issues in Git.
>
> I've looked at .gitattributes which seems to have been created by
> SubGit.
>
> There's no comment inside which makes it hard to understand.
>
> I'd like to have opinions from others on my understanding of its content
>
>
> * text=auto !eol
>
>    So, by default, Git will apply CR-LF to LF conversions automatically
>    for text files (text=auto), as per the man :
>
>        Set to string value "auto"
>
>            When text is set to "auto", the path is marked for automatic
>            end-of-line normalization. If git decides that the content is
>            text, its line endings are normalized to LF on checkin.
>
>    but I'm afraid the rest isn't clear : (!eol) : we don't want a
>    default line ending scheme ? :
>
>        Sometimes you would need to override an setting of an attribute
>        for a path to Unspecified state. This can be done by listing the
>        name of the attribute prefixed with an exclamation point !.
>
>        eol
>             This attribute sets a specific line-ending style to be used
>             in the working directory. It enables end-of-line
>             normalization without any content checks, effectively setting
>             the text attribute.
>
>    Hmm... is this contradictory ?
>
>    Anyway, then, looks like pretty much all files are listed
>    ... including .php files, marked as :
>
> src/common/dao/CodendiDataAccess.class.php -text
> src/common/dao/include/DataAccess.class.php -text
> src/common/dao/include/DataAccessException.class.php -text
> src/common/dao/include/DataAccessObject.class.php -text
> ...
>
>    which seems to mean that git will prevent normalizing them... again if
>    I read the manual right...
>
> Is this what we want ?
>
> I would say that by default we'd benefit to having CR-LF to LF
> normalization...
>
> What do you think ?
>
> Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fusionforge.org/pipermail/fusionforge-general/attachments/20121019/4f5a8b42/attachment-0001.html>


More information about the Fusionforge-general mailing list