On Tue, Oct 26, 2021 at 09:30:39PM +0200, Daniel Marschall wrote: > Am 26.10.2021 17:14, schrieb Torsten Bögershausen: > > 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) > > Thank you for your replies. > > I don't have much experience with .gitattributes, so I am not sure if I did > everything correctly. > > What I had in mind was the following: > I have files in my SVN repository which are CRLF, and some files are LF. > I wanted to tell GIT which line ending the files should have > so that they will have the exact same line endings after the repo is checked > out. I think text=auto will also do this, maybe I should try that. > > The "AFS" files are very special, though. Due to compatibility reasons, they > must be in the ancient Macintosh format (CR) otherwise the program won't > work. Do I need to state "eol=cr" then? Or will GIT automatically use the > same line endings as in the files which I have added to SVN? Git will not change files with CR as line ending: When there is neither a LF nor CRLF; then the file is "not text". git ls-files --eol | grep "^i/-text" Will list png, afs and some other. You can remove the eol=cr (it doesn't do anything useful, and it is just confusing) Better would be: *.afs -text or *.afs binary I leave it to the reader, to find out what the difference is. > > Thank you for your help! Happy to help
