Re: noob user, want checkins to all be forced to LF terminated lines

[Walter Bright <boost@digitalmars.com>]

Jonathan Nieder wrote:
> Hi again,
> 
> Some clarifications.
> 
> Walter Bright wrote:
> 
>> git is installed under Ubuntu, but I'll be checking in files that I
>> edit on both Windows and Ubuntu, so the line endings will vary
>> depending on which platform I last editted the file on. Hence, I
>> want to force them all to be LF upon checkin.
> 
> "[core] autocrlf = input" would work.  With this setting, the work
> tree is considered sacred (i.e., not touched in any magical way at
> all) but content checked in that looks like text is converted to
> use LF.
> 
> Using .gitattributes you can override the autodetection (see
> convert.c::is_binary) of text files.
> 
>>> 	[core]
>>> 		eol = lf
>> So this changes the file in the repository to lf only, but not in
>> the worktree? That's what I want.
> 
> The opposite.  This makes the file in the worktree use lf on
> checkout, if it is known to be a text file.
> 
> On Linux it is a no-op.  For files known to be text files, the version
> checked in _always_ uses LF anyway.  The setting "[core] eol = lf" is
> just a way to turn off "[core] eol = crlf".

So I'm lost again. If the version in the repository is always converted to LF, 
then why do I need to set autocrlf=input ?


> 
>> In the tracked tree? The documentation:
>>
>> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_out_and_checking_in
>>
>> says it goes in:
>>
>>  $GIT_DIR/info/attributes, .gitattributes
>>
>> so I'm confused again. Does .gitattributes go in $GIT_DIR, or in
>> $GIT_DIR/info ? And what if both of those files are there, which one
>> 'wins' ?
> 
> Though I said "in the tracked tree", it is generally the file in the
> worktree that counts.  There can be .gitattributes files in any
> subdirectory of the toplevel of the work tree.
> 
> .git/info/attributes is a place to put local attribute settings that
> should not be tracked.  It has higher precedence than the
> .gitattributes files.  As the gitattributes(5) page says:
> 
> 	git consults $GIT_DIR/info/attributes file (which has the
> 	highest precedence), .gitattributes file in the same
> 	directory as the path in question, and its parent
> 	directories up to the toplevel of the work tree (the
> 	further the directory that contains .gitattributes is
> 	from the path in question, the lower its precedence).

Ok, got it!

> 
>>> If everyone for which you want these setting to take effect uses a
>>> recent version of git, you can write “text” instead of “crlf” if
>>> you prefer.
>> git --version says I'm using 1.5.6.3
> 
> Not recent enough. :)

Eh, it's what ubuntu's apt-get gave me.


> Actually versions before 1.7.2 do not have the "[core] eol"
> configuration, either, so there is one less thing to worry about.
> 
>> A final question: where does the repository actually go (so I can
>> back it up)?
> 
> The subdirectory .git of the top level of the worktree.
> 
> You can back up with "git clone" or "git bundle", but copying the
> .git directory also works fine.

Why would "git clone" even exist if copying the directory works? Is it the 
embedded inode problem that Ilari mentioned?