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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.