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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html