Re: git-svn bug: Output git directory has uncommitted changes

> On Mon, Oct 25, 2021 at 09:41:39AM +0000, Eric Wong wrote:
>> Daniel Marschall <info@daniel-marschall.de> 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)