{"thread":{"id":"56777","subject":"git-svn bug: Output git directory has uncommitted changes","startedAt":"2021-10-24T20:19:58Z","lastAt":"2021-10-30T20:52:29Z","messageCount":6,"participants":["Daniel Marschall","Eric Wong","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439505","messageId":"77aacb3b44523223c7647bdae1702a31@daniel-marschall.de","threadId":"56777","inReplyTo":null,"subject":"git-svn bug: Output git directory has uncommitted changes","fromName":"Daniel Marschall","fromEmail":"info@daniel-marschall.de","sentAt":"2021-10-24T20:11:46Z","receivedAt":"2021-10-24T20:19:58Z","isPatch":false,"sender":{"key":"info@daniel-marschall.de","avatar":null},"body":"Hello,\n\nI have found following bug in the latest version of git-svn . I have \nthis issue with the old version shipped in Debian stable, as well as \nwith the latest version built from source.\n\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nExtract the following SVN repository to GIT: \nhttps://svn.viathinksoft.com/svn/filter_foundry/\nThe bug ONLY happens with this single SVN repository. All other SVN \nrepositories from my server work perfectly.\n\n$ PERL5LIB=perl/ ./git-svn --authors-file=\"../../authors.txt\" clone \n--trunk=\"trunk\" \"https://svn.viathinksoft.com/svn/filter_foundry/\" \n\"_test\"\n$ cd _test\n$ git status\n\nWhat did you expect to happen? (Expected behavior)\n\ngit status should show that nothing needs to be commited.\n\nWhat happened instead? (Actual behavior)\n\nYou get a long list of files which need to be committed. The list is \nsometimes longer and sometimes shorter. So, the behavior is not \ndeterministic. I have the feeling that the list often contains all files \nin the repo.\n\nAnything else you want to add:\n\nThis SVN repository was cloned from a foreign server to my own server, \nand then continued there. I think this SVN repository has some specific \nproperties that cause the bugs.\n\nAuthors.txt file (changed email addresses for privacy reasons):\n\ndaniel-marschall = Person 1 <person1@example.com>\nwww-data = Person 2 <person2@example.com>\nroot = Person 3 <person3@example.com>\ntoby = Person 4 <person4@example.com>\nddenk = Person 5 <person5@example.com>\npeter = Person 6 <person6@example.com>\ndmarschall = Person 7 <person7@example.com>\n\n\n\n[System Info]\ngit version:\ngit version 2.33.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) \nx86_64\ncompiler info: gnuc: 8.3\nlibc info: glibc: 2.28\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show\n"},{"id":"439523","messageId":"20211025094139.GA22377@dcvr","threadId":"56777","inReplyTo":"77aacb3b44523223c7647bdae1702a31@daniel-marschall.de","subject":"Re: git-svn bug: Output git directory has uncommitted changes","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-10-25T09:41:39Z","receivedAt":"2021-10-25T09:41:44Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Daniel Marschall <info@daniel-marschall.de> wrote:\n> Hello,\n> \n> I have found following bug in the latest version of git-svn . I have this\n> issue with the old version shipped in Debian stable, as well as with the\n> latest version built from source.\n> \n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> Extract the following SVN repository to GIT:\n> https://svn.viathinksoft.com/svn/filter_foundry/\n> The bug ONLY happens with this single SVN repository. All other SVN\n> repositories from my server work perfectly.\n> \n> $ PERL5LIB=perl/ ./git-svn --authors-file=\"../../authors.txt\" clone\n> --trunk=\"trunk\" \"https://svn.viathinksoft.com/svn/filter_foundry/\" \"_test\"\n> $ cd _test\n> $ git status\n> \n> What did you expect to happen? (Expected behavior)\n> \n> git status should show that nothing needs to be commited.\n> \n> What happened instead? (Actual behavior)\n> \n> You get a long list of files which need to be committed. The list is\n> sometimes longer and sometimes shorter. So, the behavior is not\n> deterministic. I have the feeling that the list often contains all files in\n> the repo.\n\nIt seems like a CRLF vs LF vs CR issue; not something I'm\nfamiliar with (not even in a git-only environment).\n\nRunning `git diff --ignore-space-change` says there aren't\nnon-space changes.\n\nThe presence of a .gitattributes file in the repo could be\nconfusing things, maybe, just a guess, I don't know...\n\nBeing a *nix-only person, I've never mucked with eol= attributes\nat all.  Maybe somebody else experienced with such issues can\nchime in; but eol stuff seems like a minefield of complexity I\ndon't ever want to step into :x\n\n> Anything else you want to add:\n> \n> This SVN repository was cloned from a foreign server to my own server, and\n> then continued there. I think this SVN repository has some specific\n> properties that cause the bugs.\n\nIt's been a while since I've looked at SVN stuff.  From what I\nremember, git-svn doesn't check the CRLF property on the SVN side.\n"},{"id":"439649","messageId":"20211026151442.65rndwsleyitxvvg@tb-raspi4","threadId":"56777","inReplyTo":"20211025094139.GA22377@dcvr","subject":"Re: git-svn bug: Output git directory has uncommitted changes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2021-10-26T15:14:42Z","receivedAt":"2021-10-26T15:14:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, Oct 25, 2021 at 09:41:39AM +0000, Eric Wong wrote:\n> Daniel Marschall <info@daniel-marschall.de> wrote:\n> > Hello,\n> >\n> > I have found following bug in the latest version of git-svn . I have this\n> > issue with the old version shipped in Debian stable, as well as with the\n> > latest version built from source.\n> >\n> >\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> >\n> > Extract the following SVN repository to GIT:\n> > https://svn.viathinksoft.com/svn/filter_foundry/\n> > The bug ONLY happens with this single SVN repository. All other SVN\n> > repositories from my server work perfectly.\n> >\n> > $ PERL5LIB=perl/ ./git-svn --authors-file=\"../../authors.txt\" clone\n> > --trunk=\"trunk\" \"https://svn.viathinksoft.com/svn/filter_foundry/\" \"_test\"\n> > $ cd _test\n> > $ git status\n> >\n> > What did you expect to happen? (Expected behavior)\n> >\n> > git status should show that nothing needs to be commited.\n> >\n> > What happened instead? (Actual behavior)\n> >\n> > You get a long list of files which need to be committed. The list is\n> > sometimes longer and sometimes shorter. So, the behavior is not\n> > deterministic. I have the feeling that the list often contains all files in\n> > the repo.\n>\n> It seems like a CRLF vs LF vs CR issue; not something I'm\n> familiar with (not even in a git-only environment).\n>\n> Running `git diff --ignore-space-change` says there aren't\n> non-space changes.\n>\n> The presence of a .gitattributes file in the repo could be\n> confusing things, maybe, just a guess, I don't know...\n>\n> Being a *nix-only person, I've never mucked with eol= attributes\n> at all.  Maybe somebody else experienced with such issues can\n> chime in; but eol stuff seems like a minefield of complexity I\n> don't ever want to step into :x\n>\n> > Anything else you want to add:\n> >\n> > This SVN repository was cloned from a foreign server to my own server, and\n> > then continued there. I think this SVN repository has some specific\n> > properties that cause the bugs.\n>\n> It's been a while since I've looked at SVN stuff.  From what I\n> remember, git-svn doesn't check the CRLF property on the SVN side.\n\nGood point, Eric\n\nAfter cloning the repo with git-svn, we can say that:\nThe .gitattributes file is in conflict with the files commited under Git\nRun\ngit ls-files --eol\nto see what is going on\n[lots of output]\n\nTo give a simpler example, run it on only one file,\nwhich is changed in my clone:\n\ngit ls-files --eol telegraphics_common/tt/wind.c\ni/crlf  w/crlf  attr/text eol=crlf telegraphics_common/tt/wind.c\n\nAnd what does this mean ?\nThe file has CRLF in the index, CRLF in the working tree and \"text\"\nThese settings are conflicting.\nThe easiest solution may be to replace\n\"text\" with \"text=auto\"\nin .gitattributes\n\nAnd, while looking at .gitignore: the \"eol=cr\" is not supported under Git:\n*.afs text eol=cr\n(But Git does not complain)\n\n\n\n\n"},{"id":"439667","messageId":"5be6fa92074fb40f3167901d203941bc@daniel-marschall.de","threadId":"56777","inReplyTo":"20211026151442.65rndwsleyitxvvg@tb-raspi4","subject":"Re: git-svn bug: Output git directory has uncommitted changes","fromName":"Daniel Marschall","fromEmail":"info@daniel-marschall.de","sentAt":"2021-10-26T19:30:39Z","receivedAt":"2021-10-26T19:31:08Z","isPatch":false,"sender":{"key":"info@daniel-marschall.de","avatar":null},"body":"Am 26.10.2021 17:14, schrieb Torsten Bögershausen:\n> On Mon, Oct 25, 2021 at 09:41:39AM +0000, Eric Wong wrote:\n>> Daniel Marschall <info@daniel-marschall.de> wrote:\n>> > Hello,\n>> >\n>> > I have found following bug in the latest version of git-svn . I have this\n>> > issue with the old version shipped in Debian stable, as well as with the\n>> > latest version built from source.\n>> >\n>> >\n>> > What did you do before the bug happened? (Steps to reproduce your issue)\n>> >\n>> > Extract the following SVN repository to GIT:\n>> > https://svn.viathinksoft.com/svn/filter_foundry/\n>> > The bug ONLY happens with this single SVN repository. All other SVN\n>> > repositories from my server work perfectly.\n>> >\n>> > $ PERL5LIB=perl/ ./git-svn --authors-file=\"../../authors.txt\" clone\n>> > --trunk=\"trunk\" \"https://svn.viathinksoft.com/svn/filter_foundry/\" \"_test\"\n>> > $ cd _test\n>> > $ git status\n>> >\n>> > What did you expect to happen? (Expected behavior)\n>> >\n>> > git status should show that nothing needs to be commited.\n>> >\n>> > What happened instead? (Actual behavior)\n>> >\n>> > You get a long list of files which need to be committed. The list is\n>> > sometimes longer and sometimes shorter. So, the behavior is not\n>> > deterministic. I have the feeling that the list often contains all files in\n>> > the repo.\n>> \n>> It seems like a CRLF vs LF vs CR issue; not something I'm\n>> familiar with (not even in a git-only environment).\n>> \n>> Running `git diff --ignore-space-change` says there aren't\n>> non-space changes.\n>> \n>> The presence of a .gitattributes file in the repo could be\n>> confusing things, maybe, just a guess, I don't know...\n>> \n>> Being a *nix-only person, I've never mucked with eol= attributes\n>> at all.  Maybe somebody else experienced with such issues can\n>> chime in; but eol stuff seems like a minefield of complexity I\n>> don't ever want to step into :x\n>> \n>> > Anything else you want to add:\n>> >\n>> > This SVN repository was cloned from a foreign server to my own server, and\n>> > then continued there. I think this SVN repository has some specific\n>> > properties that cause the bugs.\n>> \n>> It's been a while since I've looked at SVN stuff.  From what I\n>> remember, git-svn doesn't check the CRLF property on the SVN side.\n> \n> Good point, Eric\n> \n> After cloning the repo with git-svn, we can say that:\n> The .gitattributes file is in conflict with the files commited under \n> Git\n> Run\n> git ls-files --eol\n> to see what is going on\n> [lots of output]\n> \n> To give a simpler example, run it on only one file,\n> which is changed in my clone:\n> \n> git ls-files --eol telegraphics_common/tt/wind.c\n> i/crlf  w/crlf  attr/text eol=crlf telegraphics_common/tt/wind.c\n> \n> And what does this mean ?\n> The file has CRLF in the index, CRLF in the working tree and \"text\"\n> These settings are conflicting.\n> The easiest solution may be to replace\n> \"text\" with \"text=auto\"\n> in .gitattributes\n> \n> And, while looking at .gitignore: the \"eol=cr\" is not supported under \n> Git:\n> *.afs text eol=cr\n> (But Git does not complain)\n\nThank you for your replies.\n\nI don't have much experience with .gitattributes, so I am not sure if I \ndid everything correctly.\n\nWhat I had in mind was the following:\nI have files in my SVN repository which are CRLF, and some files are LF.\nI wanted to tell GIT which line ending the files should have\nso that they will have the exact same line endings after the repo is \nchecked out. I think text=auto will also do this, maybe I should try \nthat.\n\nThe \"AFS\" files are very special, though. Due to compatibility reasons, \nthey must be in the ancient Macintosh format (CR) otherwise the program \nwon't work. Do I need to state \"eol=cr\" then? Or will GIT automatically \nuse the same line endings as in the files which I have added to SVN?\n\nThank you for your help!\n"},{"id":"439788","messageId":"20211027144111.y43o4qdp3pjp6xsh@tb-raspi4","threadId":"56777","inReplyTo":"5be6fa92074fb40f3167901d203941bc@daniel-marschall.de","subject":"Re: git-svn bug: Output git directory has uncommitted changes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2021-10-27T14:41:11Z","receivedAt":"2021-10-27T14:41:18Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Oct 26, 2021 at 09:30:39PM +0200, Daniel Marschall wrote:\n> Am 26.10.2021 17:14, schrieb Torsten Bögershausen:\n> > On Mon, Oct 25, 2021 at 09:41:39AM +0000, Eric Wong wrote:\n> > > Daniel Marschall <info@daniel-marschall.de> wrote:\n> > > > Hello,\n> > > >\n> > > > I have found following bug in the latest version of git-svn . I have this\n> > > > issue with the old version shipped in Debian stable, as well as with the\n> > > > latest version built from source.\n> > > >\n> > > >\n> > > > What did you do before the bug happened? (Steps to reproduce your issue)\n> > > >\n> > > > Extract the following SVN repository to GIT:\n> > > > https://svn.viathinksoft.com/svn/filter_foundry/\n> > > > The bug ONLY happens with this single SVN repository. All other SVN\n> > > > repositories from my server work perfectly.\n> > > >\n> > > > $ PERL5LIB=perl/ ./git-svn --authors-file=\"../../authors.txt\" clone\n> > > > --trunk=\"trunk\" \"https://svn.viathinksoft.com/svn/filter_foundry/\" \"_test\"\n> > > > $ cd _test\n> > > > $ git status\n> > > >\n> > > > What did you expect to happen? (Expected behavior)\n> > > >\n> > > > git status should show that nothing needs to be commited.\n> > > >\n> > > > What happened instead? (Actual behavior)\n> > > >\n> > > > You get a long list of files which need to be committed. The list is\n> > > > sometimes longer and sometimes shorter. So, the behavior is not\n> > > > deterministic. I have the feeling that the list often contains all files in\n> > > > the repo.\n> > >\n> > > It seems like a CRLF vs LF vs CR issue; not something I'm\n> > > familiar with (not even in a git-only environment).\n> > >\n> > > Running `git diff --ignore-space-change` says there aren't\n> > > non-space changes.\n> > >\n> > > The presence of a .gitattributes file in the repo could be\n> > > confusing things, maybe, just a guess, I don't know...\n> > >\n> > > Being a *nix-only person, I've never mucked with eol= attributes\n> > > at all.  Maybe somebody else experienced with such issues can\n> > > chime in; but eol stuff seems like a minefield of complexity I\n> > > don't ever want to step into :x\n> > >\n> > > > Anything else you want to add:\n> > > >\n> > > > This SVN repository was cloned from a foreign server to my own server, and\n> > > > then continued there. I think this SVN repository has some specific\n> > > > properties that cause the bugs.\n> > >\n> > > It's been a while since I've looked at SVN stuff.  From what I\n> > > remember, git-svn doesn't check the CRLF property on the SVN side.\n> >\n> > Good point, Eric\n> >\n> > After cloning the repo with git-svn, we can say that:\n> > The .gitattributes file is in conflict with the files commited under Git\n> > Run\n> > git ls-files --eol\n> > to see what is going on\n> > [lots of output]\n> >\n> > To give a simpler example, run it on only one file,\n> > which is changed in my clone:\n> >\n> > git ls-files --eol telegraphics_common/tt/wind.c\n> > i/crlf  w/crlf  attr/text eol=crlf telegraphics_common/tt/wind.c\n> >\n> > And what does this mean ?\n> > The file has CRLF in the index, CRLF in the working tree and \"text\"\n> > These settings are conflicting.\n> > The easiest solution may be to replace\n> > \"text\" with \"text=auto\"\n> > in .gitattributes\n> >\n> > And, while looking at .gitignore: the \"eol=cr\" is not supported under\n> > Git:\n> > *.afs text eol=cr\n> > (But Git does not complain)\n>\n> Thank you for your replies.\n>\n> I don't have much experience with .gitattributes, so I am not sure if I did\n> everything correctly.\n>\n> What I had in mind was the following:\n> I have files in my SVN repository which are CRLF, and some files are LF.\n> I wanted to tell GIT which line ending the files should have\n> so that they will have the exact same line endings after the repo is checked\n> out. I think text=auto will also do this, maybe I should try that.\n>\n> The \"AFS\" files are very special, though. Due to compatibility reasons, they\n> must be in the ancient Macintosh format (CR) otherwise the program won't\n> work. Do I need to state \"eol=cr\" then? Or will GIT automatically use the\n> same line endings as in the files which I have added to SVN?\n\nGit will not change files with CR as line ending:\nWhen there is neither a LF nor CRLF; then the file is \"not text\".\n\ngit ls-files --eol  | grep \"^i/-text\"\n\nWill list png, afs and some other.\nYou can remove the eol=cr (it doesn't do anything useful, and it is just confusing)\n\nBetter would be:\n*.afs -text\nor\n*.afs binary\n\nI leave it to the reader, to find out what the difference is.\n\n>\n> Thank you for your help!\n\nHappy to help\n"},{"id":"440139","messageId":"48d96db41fbe4400b995d9e9b9e03277@daniel-marschall.de","threadId":"56777","inReplyTo":"20211027144111.y43o4qdp3pjp6xsh@tb-raspi4","subject":"Re: git-svn bug: Output git directory has uncommitted changes","fromName":"Daniel Marschall","fromEmail":"info@daniel-marschall.de","sentAt":"2021-10-30T20:52:01Z","receivedAt":"2021-10-30T20:52:29Z","isPatch":false,"sender":{"key":"info@daniel-marschall.de","avatar":null},"body":"Am 27.10.2021 16:41, schrieb Torsten Bögershausen:\n> On Tue, Oct 26, 2021 at 09:30:39PM +0200, Daniel Marschall wrote:\n>> Am 26.10.2021 17:14, schrieb Torsten Bögershausen:\n>> \n>> What I had in mind was the following:\n>> I have files in my SVN repository which are CRLF, and some files are \n>> LF.\n>> I wanted to tell GIT which line ending the files should have\n>> so that they will have the exact same line endings after the repo is \n>> checked\n>> out. I think text=auto will also do this, maybe I should try that.\n>> \n>> The \"AFS\" files are very special, though. Due to compatibility \n>> reasons, they\n>> must be in the ancient Macintosh format (CR) otherwise the program \n>> won't\n>> work. Do I need to state \"eol=cr\" then? Or will GIT automatically use \n>> the\n>> same line endings as in the files which I have added to SVN?\n> \n> Git will not change files with CR as line ending:\n> When there is neither a LF nor CRLF; then the file is \"not text\".\n> \n> git ls-files --eol  | grep \"^i/-text\"\n> \n> Will list png, afs and some other.\n> You can remove the eol=cr (it doesn't do anything useful, and it is\n> just confusing)\n\nI looked at the git documentation, but I couldn't find an official \nstatement\nthat only \"lf\" and \"crlf\" are legal values of \"eol\". I only found \nexamples of CRLF and LF,\nbut I think that doesn't mean that the lack of a CR example implies that \nCR is forbidden.\nOr did I miss something?\n\nI think it would be great if \"eol=cr\" could be implemented.\nIf you have a legacy Mac OS9 project or a project that requires files in \na\nlegacy text format, then I think it would be nice if Git could be able \nto diff these\nCR-text-files. If I treat them as binary, I think there can't be a\ntext-like diff?\n\n> \n> Better would be:\n> *.afs -text\n> or\n> *.afs binary\n> \n> I leave it to the reader, to find out what the difference is.\n\nI thought a long time about it, but I can't figure it out.\nGoogle can't help me either, because \"-text\" is will be treated as an \nexclusion in the search term.\n\nCan you please tell me what the difference is?\nI have the theory that \"binary\" tells Git to handle it binary, while \n\"-text\" tells Git to handle it neither as binary nor as text \n(\"undefined\")?\n\n"}]}