On Mon, Oct 25, 2021 at 09:41:39AM +0000, Eric Wong wrote: > Daniel Marschall <info@xxxxxxxxxxxxxxxxxxx> wrote: > > Hello, > > > > I have found following bug in the latest version of git-svn . I have this > > issue with the old version shipped in Debian stable, as well as with the > > latest version built from source. > > > > > > What did you do before the bug happened? (Steps to reproduce your issue) > > > > Extract the following SVN repository to GIT: > > https://svn.viathinksoft.com/svn/filter_foundry/ > > The bug ONLY happens with this single SVN repository. All other SVN > > repositories from my server work perfectly. > > > > $ PERL5LIB=perl/ ./git-svn --authors-file="../../authors.txt" clone > > --trunk="trunk" "https://svn.viathinksoft.com/svn/filter_foundry/"; "_test" > > $ cd _test > > $ git status > > > > What did you expect to happen? (Expected behavior) > > > > git status should show that nothing needs to be commited. > > > > What happened instead? (Actual behavior) > > > > You get a long list of files which need to be committed. The list is > > sometimes longer and sometimes shorter. So, the behavior is not > > deterministic. I have the feeling that the list often contains all files in > > the repo. > > It seems like a CRLF vs LF vs CR issue; not something I'm > familiar with (not even in a git-only environment). > > Running `git diff --ignore-space-change` says there aren't > non-space changes. > > The presence of a .gitattributes file in the repo could be > confusing things, maybe, just a guess, I don't know... > > Being a *nix-only person, I've never mucked with eol= attributes > at all. Maybe somebody else experienced with such issues can > chime in; but eol stuff seems like a minefield of complexity I > don't ever want to step into :x > > > Anything else you want to add: > > > > This SVN repository was cloned from a foreign server to my own server, and > > then continued there. I think this SVN repository has some specific > > properties that cause the bugs. > > It's been a while since I've looked at SVN stuff. From what I > remember, git-svn doesn't check the CRLF property on the SVN side. Good point, Eric After cloning the repo with git-svn, we can say that: The .gitattributes file is in conflict with the files commited under Git Run git ls-files --eol to see what is going on [lots of output] To give a simpler example, run it on only one file, which is changed in my clone: git ls-files --eol telegraphics_common/tt/wind.c i/crlf w/crlf attr/text eol=crlf telegraphics_common/tt/wind.c And what does this mean ? The file has CRLF in the index, CRLF in the working tree and "text" These settings are conflicting. The easiest solution may be to replace "text" with "text=auto" in .gitattributes And, while looking at .gitignore: the "eol=cr" is not supported under Git: *.afs text eol=cr (But Git does not complain)
