On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
On Tue, 4 Nov 2008, Andrew Arnott wrote:
It was the CRLF conversion. When I played around with
git config --global core.autocrlf true/false
I got the problem to eventually go away.
Thanks for all your responses.
It's still worth debugging further, because git should know that it
wrote
the files differently and not see that as changes. It's not too
helpful to
have autocrlf if it causes this problem.
I think I know what this is. If a repository contains files with
CRLFs, those files will show as modified when core.autcorlf is true
(if you commit them, the CRLFs will be converted to CRs in the
repository, so in a sense they _are_ modified). Try turning autocrlf
back on, cloning the repository, then touching all the files (to make
git check them for changes) and see if you get the same problem.
I proposed an alternative autocrlf implementation on the list a while
back: making it an attribute instead of a configuration setting and
adding a configuration setting to tell git which line ending is
preferred when the autocrlf attribute is set.
That would allow you to turn on autocrlf and let git convert all CRLFs
to CRs in a single commit, thus converting a repository with CRLFs to
one that can be used with autocrlf in a versioned way. In theory that
lets you check out new commits with EOL conversion while old commits
will be left alone (avoiding the problem you saw), but
since .gitattributes is read from the working directory and not the
tree to be checked out, it doesn't work perfectly.
I implemented the easy bit (reading autocrlf from .gitattributes), but
for various reasons the patch has just been gathering dust in my
private git.git repo. Maybe I should dust it off :)
--
Eyvind
--
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
