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

From: Eric Wong <e@80x24.org>
Date: Oct 25, 2021, 09:41 UTC
Message-ID: <20211025094139.GA22377@dcvr>
In-Reply-To: <77aacb3b44523223c7647bdae1702a31@daniel-marschall.de>

Daniel Marschall <info@daniel-marschall.de> wrote:

Show 29 quoted lines

> 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

Show 5 quoted lines

> 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.