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