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

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

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@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)
>
> 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