From: Eric Wong <e@80x24.org>
To: Daniel Marschall <info@daniel-marschall.de>
Cc: git@vger.kernel.org
Subject: Re: git-svn bug: Output git directory has uncommitted changes
Date: Mon, 25 Oct 2021 09:41:39 +0000 [thread overview]
Message-ID: <20211025094139.GA22377@dcvr> (raw)
In-Reply-To: <77aacb3b44523223c7647bdae1702a31@daniel-marschall.de>
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.
next prev parent reply other threads:[~2021-10-25 9:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-24 20:11 git-svn bug: Output git directory has uncommitted changes Daniel Marschall
2021-10-25 9:41 ` Eric Wong [this message]
2021-10-26 15:14 ` Torsten Bögershausen
2021-10-26 19:30 ` Daniel Marschall
2021-10-27 14:41 ` Torsten Bögershausen
2021-10-30 20:52 ` Daniel Marschall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211025094139.GA22377@dcvr \
--to=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=info@daniel-marschall.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).