From: Johannes Schindelin <hidden> Date: 2016-06-15 22:48:23
Hi,
back then, I was not a fan of the core.autocrlf support. But I have to
admit that in the meantime, I turned into an outright un-fan of the
feature. Not because its intent is wrong, but because its implementation
is lousy.
Just try to "git reset --hard" or "git stash" when there are files with
DOS line endings and when core.autocrlf is not false.
And then despair.
So again, for the record this time: core.autocrlf=true is handled
_lousily_.
Ciao,
Dscho
On Sat, Mar 06, 2010 at 12:23:33AM +0100, Johannes Schindelin wrote:
back then, I was not a fan of the core.autocrlf support. But I have to
admit that in the meantime, I turned into an outright un-fan of the
feature. Not because its intent is wrong, but because its implementation
is lousy.
Well, I agree there are some issues with it. In particularly, when
someone changes core.autocrlf in his/her repository, and then git
behavior is outright confusing. IMHO, the nuts of the problem is that
does not store in the index how files were checkout. Instead it uses
core.autocrlf, which specifies how the user _wants_ files to be check-
out. So, when the autocrlf option changes, things get very confusing.
However:
Just try to "git reset --hard" or "git stash" when there are files with
DOS line endings and when core.autocrlf is not false.
I did, and I have not noticed any problem with that.
git init
git config core.autocrlf true
echo foo^ | tr ^ '\r' > foo
git add foo
git commit -m 'add foo'
echo more^ | tr ^ '\r' >> foo
echo "Before reset:"
tr '\r' ^ < foo
git reset --hard
echo "After reset:"
git diff
tr '\r' ^ < foo
Dmitry
Well, I agree there are some issues with it. In particularly, when
someone changes core.autocrlf in his/her repository, and then git
behavior is outright confusing. IMHO, the nuts of the problem is that
does not store in the index how files were checkout. Instead it uses
core.autocrlf, which specifies how the user _wants_ files to be check-
out. So, when the autocrlf option changes, things get very confusing.
I do agree. It would probably have been a good idea to mark the CRLF
status in the index, but we didn't. And crlf isn't actually the _only_
thing that can cause confusion, the 'ident' and 'filter' can do the same
thing.
One option might be to have "git config" know about crlf, so that if you
change crlf state with 'git config' rather than manually, we could at
least _warn_ about the effects and tell people that they may need to do a
full new checkout (or reset the stat info in the index, or whatever). But
I like editing config files by hand, and I don't think I'm the only one.
Linus
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:48:24
Hi,
On Sun, 7 Mar 2010, Dmitry Potapov wrote:
On Sat, Mar 06, 2010 at 12:23:33AM +0100, Johannes Schindelin wrote:
quoted
Just try to "git reset --hard" or "git stash" when there are files
with DOS line endings and when core.autocrlf is not false.
I did, and I have not noticed any problem with that.
git init
git config core.autocrlf true
echo foo^ | tr ^ '\r' > foo
git add foo
git commit -m 'add foo'
Unfortunately, this is not the common case. The common case is that
somebody committed _without_ autocrlf (implicitly =false), and you clone
from there.
Easiest example:
$ git clone -n git://repo.or.cz/git.git html-docs
$ cd html-docs/
$ git config core.autocrlf true
$ git checkout -t origin/html
$ git status
... and despair.
Hth,
Dscho
I do agree. It would probably have been a good idea to mark the CRLF
status in the index, but we didn't...
We already have .gitattributes for tracking information about files. Maybe
add an attribute to describe the in-repository line endings? The default
would be LF, as now, and a new attribute could change the checked-in
format to be CRLF.
Tait
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:48:24
Hi,
On Mon, 8 Mar 2010, Tait wrote:
quoted
I do agree. It would probably have been a good idea to mark the CRLF
status in the index, but we didn't...
We already have .gitattributes for tracking information about files.
Maybe add an attribute to describe the in-repository line endings? The
default would be LF, as now, and a new attribute could change the
checked-in format to be CRLF.
No.
The problem is not the description of the line endings in the repository.
The information what line endings are used can be easily extracted from
every blob, by a simple inspection.
The problem is that the core.autocrlf code blindly assumes that Unix line
endings are the only thing you would ever commit. And worse, the mistake
is repeated when updating the index. Git converts the DOS line endings
into Unix line endings, then compares with what it has in the repository
and says: "Ooops, it is different!" even if it just checked the files out.
And I demonstrated with the "html" example that even long-time Gitsters
sometimes commit DOS line endings as-are, unconverted.
Ciao,
Dscho
As Junio explained in another mail, it was intentional to have all HTML
files with CRLF, because they are supposed to have that ending on all
platforms. What is missing, however, is .gitattributes, which would tell
to Git that we do not want to autocrlf conversion for HTML files.
That is just papering over the real culprit: Git checks something out.
This should be clean. But then Git says it is not.
Ciao,
Dscho
As Junio explained in another mail, it was intentional to have all HTML
files with CRLF, because they are supposed to have that ending on all
platforms. What is missing, however, is .gitattributes, which would tell
to Git that we do not want to autocrlf conversion for HTML files. This
can be done by adding .gitattributes:
$ cat >> .gitattributes <<EOF
*.html -crlf
EOF
I've just noticed that user-manual.html differs from other HTML files in
that it uses LF ending. I think it is a mistake, and this file should be
converted to have CRLF, but if you want to have all HTML files except
user-manual.html to have CRLF then you can do that too:
$ cat > .gitattributes <<EOF
*.html -crlf
user-manual.html crlf
EOF
I hope Junio will add the right version of .gitattributes, so users with
autocrlf=true will not suffer.
Dmitry
On Tue, Mar 09, 2010 at 10:29:20AM +0100, Johannes Schindelin wrote:
That is just papering over the real culprit: Git checks something out.
This should be clean. But then Git says it is not.
We have two filters: from-git-to-worktree and from-worktree-to-git. If
those conversions are inconsistent for whatever reason, it is not going
to be well even if we found a way to solve this not-being-clean-after-
checkout problem.
One possible approach is to mark all files that had CRLF conversion
during checkout and apply the opposite conversion only to them. But what
about newly added files? Wouldn't this lead that to the situation where
newly added files will have the incorrect ending?
IMHO, this not clean after checkout repo demonstrates that you have the
incorrectly crlf configuration in it. So, you probably should correct
.gitattributes (or even to disable autocrlf in it if this repository is
not intended to be used with autocrlf=true). Either way, your current
settings are incorrect. It is better to fix it than try to hide it!
Dmitry