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.
