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

["Torsten Bögershausen" <tboegi@web.de>]

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)