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?
Thank you for your help!
