* git-svn bug: Output git directory has uncommitted changes
@ 2021-10-24 20:11 Daniel Marschall
2021-10-25 9:41 ` Eric Wong
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Marschall @ 2021-10-24 20:11 UTC (permalink / raw)
To: git
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.
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.
Authors.txt file (changed email addresses for privacy reasons):
daniel-marschall = Person 1 <person1@example.com>
www-data = Person 2 <person2@example.com>
root = Person 3 <person3@example.com>
toby = Person 4 <person4@example.com>
ddenk = Person 5 <person5@example.com>
peter = Person 6 <person6@example.com>
dmarschall = Person 7 <person7@example.com>
[System Info]
git version:
git version 2.33.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18)
x86_64
compiler info: gnuc: 8.3
libc info: glibc: 2.28
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-svn bug: Output git directory has uncommitted changes
2021-10-24 20:11 git-svn bug: Output git directory has uncommitted changes Daniel Marschall
@ 2021-10-25 9:41 ` Eric Wong
2021-10-26 15:14 ` Torsten Bögershausen
0 siblings, 1 reply; 6+ messages in thread
From: Eric Wong @ 2021-10-25 9:41 UTC (permalink / raw)
To: Daniel Marschall; +Cc: git
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-svn bug: Output git directory has uncommitted changes
2021-10-25 9:41 ` Eric Wong
@ 2021-10-26 15:14 ` Torsten Bögershausen
2021-10-26 19:30 ` Daniel Marschall
0 siblings, 1 reply; 6+ messages in thread
From: Torsten Bögershausen @ 2021-10-26 15:14 UTC (permalink / raw)
To: Eric Wong; +Cc: Daniel Marschall, git
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-svn bug: Output git directory has uncommitted changes
2021-10-26 15:14 ` Torsten Bögershausen
@ 2021-10-26 19:30 ` Daniel Marschall
2021-10-27 14:41 ` Torsten Bögershausen
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Marschall @ 2021-10-26 19:30 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Eric Wong, git
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?
Thank you for your help!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-svn bug: Output git directory has uncommitted changes
2021-10-26 19:30 ` Daniel Marschall
@ 2021-10-27 14:41 ` Torsten Bögershausen
2021-10-30 20:52 ` Daniel Marschall
0 siblings, 1 reply; 6+ messages in thread
From: Torsten Bögershausen @ 2021-10-27 14:41 UTC (permalink / raw)
To: Daniel Marschall; +Cc: Eric Wong, git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-svn bug: Output git directory has uncommitted changes
2021-10-27 14:41 ` Torsten Bögershausen
@ 2021-10-30 20:52 ` Daniel Marschall
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Marschall @ 2021-10-30 20:52 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Torsten Bögershausen
Am 27.10.2021 16:41, schrieb Torsten Bögershausen:
> On Tue, Oct 26, 2021 at 09:30:39PM +0200, Daniel Marschall wrote:
>> Am 26.10.2021 17:14, schrieb Torsten Bögershausen:
>>
>> 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)
I looked at the git documentation, but I couldn't find an official
statement
that only "lf" and "crlf" are legal values of "eol". I only found
examples of CRLF and LF,
but I think that doesn't mean that the lack of a CR example implies that
CR is forbidden.
Or did I miss something?
I think it would be great if "eol=cr" could be implemented.
If you have a legacy Mac OS9 project or a project that requires files in
a
legacy text format, then I think it would be nice if Git could be able
to diff these
CR-text-files. If I treat them as binary, I think there can't be a
text-like diff?
>
> Better would be:
> *.afs -text
> or
> *.afs binary
>
> I leave it to the reader, to find out what the difference is.
I thought a long time about it, but I can't figure it out.
Google can't help me either, because "-text" is will be treated as an
exclusion in the search term.
Can you please tell me what the difference is?
I have the theory that "binary" tells Git to handle it binary, while
"-text" tells Git to handle it neither as binary nor as text
("undefined")?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-30 20:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-24 20:11 git-svn bug: Output git directory has uncommitted changes Daniel Marschall
2021-10-25 9:41 ` Eric Wong
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
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).