{"thread":{"id":"16162","subject":"Repo corrupted somehow?","startedAt":"2008-11-04T07:09:03Z","lastAt":"2008-11-08T15:19:13Z","messageCount":9,"participants":["Andrew Arnott","Jeff King","Daniel Barkalow","Eyvind Bernhardsen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94861","messageId":"216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com","threadId":"16162","inReplyTo":null,"subject":"Repo corrupted somehow?","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-04T07:09:03Z","receivedAt":"2008-11-04T07:09:03Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"I was just git commit'ing, and then I was doing a git rebase to squash\nseveral commits into one when the rebase failed. I then did a\ngit checkout -f master\ngit reset --hard\nbut no matter what I do, git thinks that several files have changed.\nThe diff shows all the lines in these several files removed and then\nadded, yet without any changes made to them. git reset --hard doesn't\nrevert the change. When I jump around history with git checkout these\nfiles remain in their \"changed\" state. I even tried \"git clone\" to\ncreate a whole new repo, but one of these several files STILL\nregistered as changed before I made any changes.\n\nAny idea what's wrong and how to recover?\n\nObserve the below command buffer: (I can upload my repo so you can\nclone it and perhaps repro it if you want).\n\nAndrew@LACKY /c/git/dotnetoauth\n$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: tools/Documentation.targets\n# modified: tools/DotNetOpenAuth.Common.Settings.targets\n# modified: tools/DotNetOpenAuth.Versioning.targets\n# modified:\ntools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n# modified: tools/libcheck.ps1\n# modified: tools/sandcastle.targets\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nAndrew@LACKY /c/git/dotnetoauth\n$ git reset --hard\nHEAD is now at 13d37b8 Patching up the bad merges in the phases.\n\nAndrew@LACKY /c/git/dotnetoauth\n$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: tools/Documentation.targets\n# modified: tools/DotNetOpenAuth.Common.Settings.targets\n# modified: tools/DotNetOpenAuth.Versioning.targets\n# modified:\ntools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n# modified: tools/libcheck.ps1\n# modified: tools/sandcastle.targets\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n"},{"id":"94865","messageId":"216e54900811032334y35ada7daw753c0ad3073c0317@mail.gmail.com","threadId":"16162","inReplyTo":"216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-04T07:34:12Z","receivedAt":"2008-11-04T07:34:12Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"I guess I was still in the middle of a rebase. git rebase --abort\nsort of ultimately fixed it.\n\nOn Mon, Nov 3, 2008 at 11:09 PM, Andrew Arnott wrote:\n> I was just git commit'ing, and then I was doing a git rebase to squash\n> several commits into one when the rebase failed. I then did a\n> git checkout -f master\n> git reset --hard\n> but no matter what I do, git thinks that several files have changed.\n> The diff shows all the lines in these several files removed and then\n> added, yet without any changes made to them. git reset --hard doesn't\n> revert the change. When I jump around history with git checkout these\n> files remain in their \"changed\" state. I even tried \"git clone\" to\n> create a whole new repo, but one of these several files STILL\n> registered as changed before I made any changes.\n>\n> Any idea what's wrong and how to recover?\n>\n> Observe the below command buffer: (I can upload my repo so you can\n> clone it and perhaps repro it if you want).\n>\n> Andrew@LACKY /c/git/dotnetoauth\n> $ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: tools/Documentation.targets\n> # modified: tools/DotNetOpenAuth.Common.Settings.targets\n> # modified: tools/DotNetOpenAuth.Versioning.targets\n> # modified:\n> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n> # modified: tools/libcheck.ps1\n> # modified: tools/sandcastle.targets\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>\n> Andrew@LACKY /c/git/dotnetoauth\n> $ git reset --hard\n> HEAD is now at 13d37b8 Patching up the bad merges in the phases.\n>\n> Andrew@LACKY /c/git/dotnetoauth\n> $ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: tools/Documentation.targets\n> # modified: tools/DotNetOpenAuth.Common.Settings.targets\n> # modified: tools/DotNetOpenAuth.Versioning.targets\n> # modified:\n> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n> # modified: tools/libcheck.ps1\n> # modified: tools/sandcastle.targets\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>\n"},{"id":"94895","messageId":"216e54900811040712k51db6fbfu44c59d9f90f1eabd@mail.gmail.com","threadId":"16162","inReplyTo":"216e54900811032334y35ada7daw753c0ad3073c0317@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-04T15:12:40Z","receivedAt":"2008-11-04T15:12:40Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"Nah, that wasn't a false alarm after all. It's happening again, only\nthis time for dozens of files, and\ngit rebase --abort\ngit reset --hard\n\nis not helping.\n\nOn Mon, Nov 3, 2008 at 11:34 PM, Andrew Arnott wrote:\n> I guess I was still in the middle of a rebase. git rebase --abort\n> sort of ultimately fixed it.\n>\n> On Mon, Nov 3, 2008 at 11:09 PM, Andrew Arnott wrote:\n>> I was just git commit'ing, and then I was doing a git rebase to squash\n>> several commits into one when the rebase failed. I then did a\n>> git checkout -f master\n>> git reset --hard\n>> but no matter what I do, git thinks that several files have changed.\n>> The diff shows all the lines in these several files removed and then\n>> added, yet without any changes made to them. git reset --hard doesn't\n>> revert the change. When I jump around history with git checkout these\n>> files remain in their \"changed\" state. I even tried \"git clone\" to\n>> create a whole new repo, but one of these several files STILL\n>> registered as changed before I made any changes.\n>>\n>> Any idea what's wrong and how to recover?\n>>\n>> Observe the below command buffer: (I can upload my repo so you can\n>> clone it and perhaps repro it if you want).\n>>\n>> Andrew@LACKY /c/git/dotnetoauth\n>> $ git status\n>> # On branch master\n>> # Changed but not updated:\n>> # (use \"git add ...\" to update what will be committed)\n>> #\n>> # modified: tools/Documentation.targets\n>> # modified: tools/DotNetOpenAuth.Common.Settings.targets\n>> # modified: tools/DotNetOpenAuth.Versioning.targets\n>> # modified:\n>> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n>> # modified: tools/libcheck.ps1\n>> # modified: tools/sandcastle.targets\n>> #\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>>\n>> Andrew@LACKY /c/git/dotnetoauth\n>> $ git reset --hard\n>> HEAD is now at 13d37b8 Patching up the bad merges in the phases.\n>>\n>> Andrew@LACKY /c/git/dotnetoauth\n>> $ git status\n>> # On branch master\n>> # Changed but not updated:\n>> # (use \"git add ...\" to update what will be committed)\n>> #\n>> # modified: tools/Documentation.targets\n>> # modified: tools/DotNetOpenAuth.Common.Settings.targets\n>> # modified: tools/DotNetOpenAuth.Versioning.targets\n>> # modified:\n>> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml\n>> # modified: tools/libcheck.ps1\n>> # modified: tools/sandcastle.targets\n>> #\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>>\n>\n"},{"id":"94954","messageId":"20081105032943.GA24886@coredump.intra.peff.net","threadId":"16162","inReplyTo":"216e54900811040712k51db6fbfu44c59d9f90f1eabd@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-05T03:29:43Z","receivedAt":"2008-11-05T03:29:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 04, 2008 at 07:12:40AM -0800, Andrew Arnott wrote:\n\n> Nah, that wasn't a false alarm after all. It's happening again, only\n> this time for dozens of files, and\n> git rebase --abort\n> git reset --hard\n> \n> is not helping.\n\nThis is certainly unusual. Can you provide a tarball of your repo\n(including .git and working tree)? I don't know that a clone will be\nsufficient if there is something funny going on in your local git index.\n\n-Peff\n"},{"id":"94957","messageId":"alpine.LNX.1.00.0811042241450.19665@iabervon.org","threadId":"16162","inReplyTo":"216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-05T04:21:44Z","receivedAt":"2008-11-05T04:21:44Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 3 Nov 2008, Andrew Arnott wrote:\n\n> I was just git commit'ing, and then I was doing a git rebase to squash\n> several commits into one when the rebase failed. I then did a\n> git checkout -f master\n> git reset --hard\n> but no matter what I do, git thinks that several files have changed.\n> The diff shows all the lines in these several files removed and then\n> added, yet without any changes made to them.\n\nThat sounds like some failure of CRLF conversion, like it's converting all \nof the line endings somehow when writing to the working tree and then not \nexpecting them to be different. Do you have some sort of interesting \nconfiguration for those? I wonder if you've got a .gitattributes that \nmatches the names that git uses for the files, but are on a \ncase-insensitive filesystem which lists those files in a way where their \nnames don't match (or vice versa).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"94958","messageId":"216e54900811042140l33bd7cc4ndf7f2524b9d886f1@mail.gmail.com","threadId":"16162","inReplyTo":"216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-05T05:40:22Z","receivedAt":"2008-11-05T05:40:22Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"It was the CRLF conversion. When I played around with\ngit config --global core.autocrlf true/false\nI got the problem to eventually go away.\n\nThanks for all your responses.\n\n>\n> On Tue, Nov 4, 2008 at 8:21 PM, Daniel Barkalow wrote:\n>>\n>> On Mon, 3 Nov 2008, Andrew Arnott wrote:\n>>\n>> > I was just git commit'ing, and then I was doing a git rebase to squash\n>> > several commits into one when the rebase failed. I then did a\n>> > git checkout -f master\n>> > git reset --hard\n>> > but no matter what I do, git thinks that several files have changed.\n>> > The diff shows all the lines in these several files removed and then\n>> > added, yet without any changes made to them.\n>>\n>> That sounds like some failure of CRLF conversion, like it's converting all\n>> of the line endings somehow when writing to the working tree and then not\n>> expecting them to be different. Do you have some sort of interesting\n>> configuration for those? I wonder if you've got a .gitattributes that\n>> matches the names that git uses for the files, but are on a\n>> case-insensitive filesystem which lists those files in a way where their\n>> names don't match (or vice versa).\n>>\n>> -Daniel\n>> *This .sig left intentionally blank*\n>\n"},{"id":"94959","messageId":"alpine.LNX.1.00.0811050043030.19665@iabervon.org","threadId":"16162","inReplyTo":"216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com","subject":"Re: Repo corrupted somehow?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-05T05:56:06Z","receivedAt":"2008-11-05T05:56:06Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 4 Nov 2008, Andrew Arnott wrote:\n\n> It was the CRLF conversion. When I played around with\n> git config --global core.autocrlf true/false\n> I got the problem to eventually go away.\n> \n> Thanks for all your responses.\n\nIt's still worth debugging further, because git should know that it wrote \nthe files differently and not see that as changes. It's not too helpful to \nhave autocrlf if it causes this problem.\n\nAre you using something (like .gitattributes) to mark files as text or as \nnon-text? Is this under Cygwin? It might be fixed in a newer version, \nalso.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"94971","messageId":"77005B51-0170-42EC-BBA7-DCF39C7CFC5E@orakel.ntnu.no","threadId":"16162","inReplyTo":"alpine.LNX.1.00.0811050043030.19665@iabervon.org","subject":"Re: Repo corrupted somehow?","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-11-05T12:26:59Z","receivedAt":"2008-11-05T12:26:59Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:\n\n> On Tue, 4 Nov 2008, Andrew Arnott wrote:\n>\n>> It was the CRLF conversion. When I played around with\n>> git config --global core.autocrlf true/false\n>> I got the problem to eventually go away.\n>>\n>> Thanks for all your responses.\n>\n> It's still worth debugging further, because git should know that it \n> wrote\n> the files differently and not see that as changes. It's not too \n> helpful to\n> have autocrlf if it causes this problem.\n\nI think I know what this is. If a repository contains files with \nCRLFs, those files will show as modified when core.autcorlf is true \n(if you commit them, the CRLFs will be converted to CRs in the \nrepository, so in a sense they _are_ modified). Try turning autocrlf \nback on, cloning the repository, then touching all the files (to make \ngit check them for changes) and see if you get the same problem.\n\nI proposed an alternative autocrlf implementation on the list a while \nback: making it an attribute instead of a configuration setting and \nadding a configuration setting to tell git which line ending is \npreferred when the autocrlf attribute is set.\n\nThat would allow you to turn on autocrlf and let git convert all CRLFs \nto CRs in a single commit, thus converting a repository with CRLFs to \none that can be used with autocrlf in a versioned way. In theory that \nlets you check out new commits with EOL conversion while old commits \nwill be left alone (avoiding the problem you saw), but \nsince .gitattributes is read from the working directory and not the \ntree to be checked out, it doesn't work perfectly.\n\nI implemented the easy bit (reading autocrlf from .gitattributes), but \nfor various reasons the patch has just been gathering dust in my \nprivate git.git repo. Maybe I should dust it off :)\n-- \nEyvind\n"},{"id":"95220","messageId":"216e54900811080719i43b4a631p241e9d2a54ed5ce9@mail.gmail.com","threadId":"16162","inReplyTo":"77005B51-0170-42EC-BBA7-DCF39C7CFC5E@orakel.ntnu.no","subject":"Re: Repo corrupted somehow?","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-08T15:19:13Z","receivedAt":"2008-11-08T15:19:13Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"I thought that autocrlf always 'added' CRLF instead of adding merely\nCR. Dang. I'd rather have CRLF text files.\n\nOn Wed, Nov 5, 2008 at 4:26 AM, Eyvind Bernhardsen\n wrote:\n> On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:\n>\n>> On Tue, 4 Nov 2008, Andrew Arnott wrote:\n>>\n>>> It was the CRLF conversion. When I played around with\n>>> git config --global core.autocrlf true/false\n>>> I got the problem to eventually go away.\n>>>\n>>> Thanks for all your responses.\n>>\n>> It's still worth debugging further, because git should know that it wrote\n>> the files differently and not see that as changes. It's not too helpful to\n>> have autocrlf if it causes this problem.\n>\n> I think I know what this is. If a repository contains files with CRLFs,\n> those files will show as modified when core.autcorlf is true (if you commit\n> them, the CRLFs will be converted to CRs in the repository, so in a sense\n> they _are_ modified). Try turning autocrlf back on, cloning the repository,\n> then touching all the files (to make git check them for changes) and see if\n> you get the same problem.\n>\n> I proposed an alternative autocrlf implementation on the list a while back:\n> making it an attribute instead of a configuration setting and adding a\n> configuration setting to tell git which line ending is preferred when the\n> autocrlf attribute is set.\n>\n> That would allow you to turn on autocrlf and let git convert all CRLFs to\n> CRs in a single commit, thus converting a repository with CRLFs to one that\n> can be used with autocrlf in a versioned way. In theory that lets you check\n> out new commits with EOL conversion while old commits will be left alone\n> (avoiding the problem you saw), but since .gitattributes is read from the\n> working directory and not the tree to be checked out, it doesn't work\n> perfectly.\n>\n> I implemented the easy bit (reading autocrlf from .gitattributes), but for\n> various reasons the patch has just been gathering dust in my private git.git\n> repo. Maybe I should dust it off :)\n> --\n> Eyvind\n>\n>\n"}]}