Re: noob user, want checkins to all be forced to LF terminated lines
- From
- Walter Bright <boost@digitalmars.com>
- Date
- Jul 31, 2010, 06:32 UTC
- Message-ID
- <i30g2s$dpt$1@dough.gmane.org>
- In-Reply-To
- <20100731054437.GD14425@burratino>
Jonathan Nieder wrote:
Show 30 quoted lines
> 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 ?
Show 27 quoted lines
> >> 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!
Show 7 quoted lines
> >>> 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.
Show 10 quoted lines
> 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?