{"thread":{"id":"14863","subject":"git reset --hard isn't resetting","startedAt":"2008-08-06T16:41:43Z","lastAt":"2008-08-09T08:08:25Z","messageCount":6,"participants":["Matt Graham","Dmitry Potapov","Avery Pennarun","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86359","messageId":"1c5969370808060941q59cb8f7fhabee3ef3c5107715@mail.gmail.com","threadId":"14863","inReplyTo":null,"subject":"git reset --hard isn't resetting","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2008-08-06T16:41:43Z","receivedAt":"2008-08-06T16:41:43Z","isPatch":false,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"Hi,\nI'm using a git svn tree in Cygwin. I tried doing an svn rebase and\ngot in some weird state with local changes I can't get rid of. It's\nnot an issue w/ the same repository on my linux machine.\n\ngit reset --hard\ntoggles 4 files between capitalization. The files don't appear to\nhave changed case in svn, but it's a huge repository and not easy to\ndetermine with certainty.\n\nI first encountered this during a rebase, so I rebranched master from\ngit-svn HEAD and the problem followed me there.\n\nAny tips about how to work around it or investigate further would be\nappreciated.\n\nscrollback of toggling filenames is pasted below.\n\nthanks\n\n\nmgraham@mgraham-wks /src/project.git\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: dim_grade.dsx\n# modified: dim_institution.dsx\n# modified: dim_section.dsx\n# modified: dim_term.dsx\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nmgraham@mgraham-wks /src/project.git\n$ git reset --hard\nHEAD is now at 6170b8f RPrasad - For the time being switched to\nMockAuthenticator; while working on resolving the LDAP issue.\n\nmgraham@mgraham-wks /src/project.git\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: DIM_GRADE.dsx\n# modified: DIM_INSTITUTION.dsx\n# modified: DIM_SECTION.dsx\n# modified: DIM_TERM.dsx\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n"},{"id":"86362","messageId":"37fcd2780808061101p6b75a663hb54f3cb6ad88314f@mail.gmail.com","threadId":"14863","inReplyTo":"1c5969370808060941q59cb8f7fhabee3ef3c5107715@mail.gmail.com","subject":"Re: git reset --hard isn't resetting","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-08-06T18:01:42Z","receivedAt":"2008-08-06T18:01:42Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi,\n\nOn Wed, Aug 6, 2008 at 8:41 PM, Matt Graham wrote:\n> I'm using a git svn tree in Cygwin. I tried doing an svn rebase and\n> got in some weird state with local changes I can't get rid of. It's\n> not an issue w/ the same repository on my linux machine.\n>\n> git reset --hard\n> toggles 4 files between capitalization. The files don't appear to\n> have changed case in svn, but it's a huge repository and not easy to\n> determine with certainty.\n\nWhat version of Git do you use?\nWas this repo created with Git prior 1.5.6?\nDo you have core.ignorecase set to true in .git/config?\n\nWhat \"git ls-files\" says for these files?\nWhat \"ls\" says for these files?\n\nDmitry\n"},{"id":"86363","messageId":"32541b130808061102q752076a8ydc02fef4e799491f@mail.gmail.com","threadId":"14863","inReplyTo":"1c5969370808060941q59cb8f7fhabee3ef3c5107715@mail.gmail.com","subject":"Re: git reset --hard isn't resetting","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-06T18:02:44Z","receivedAt":"2008-08-06T18:02:44Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 8/6/08, Matt Graham wrote:\n> I'm using a git svn tree in Cygwin. I tried doing an svn rebase and\n> got in some weird state with local changes I can't get rid of. It's\n> not an issue w/ the same repository on my linux machine.\n>\n> git reset --hard\n> toggles 4 files between capitalization. The files don't appear to\n> have changed case in svn, but it's a huge repository and not easy to\n> determine with certainty.\n\nTry:\n git log --name-only\nto see which patches change which files. It's a virtual certainty\nthat they were renamed in svn at some point.\n\ngit doesn't handle case-munging filesystems perfectly, and gets into\nthe situation you describe. First, you need to figure out whether you\nhave files with *both* cases accidentally added to your index (if git\nreset toggles the capitalization, this is almost certainly the case):\n\n git ls-tree HEAD\n\nIf you see the same files with different case, that's your problem.\n\nNow just 'git rm' the ones with the case you don't want, and commit\nthe result. (Do *not* use commit -a!) 'git status' will give you\nsome funny messages indicating that files you *didn't* 'git rm' have\ngone away in the filesystem; it's true, of course, but don't worry\nabout that. Now 'git reset --hard HEAD' and you should be okay.\n\nI'm not really sure what git should do better in this case, although\nthe current behaviour is obviously a bit confusing.\n\nHave fun,\n\nAvery\n"},{"id":"86448","messageId":"1c5969370808071806g1f989260n55a4b8bebfedb6e@mail.gmail.com","threadId":"14863","inReplyTo":"32541b130808061102q752076a8ydc02fef4e799491f@mail.gmail.com","subject":"Re: git reset --hard isn't resetting","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2008-08-08T01:06:27Z","receivedAt":"2008-08-08T01:06:27Z","isPatch":false,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun wrote:\n> On 8/6/08, Matt Graham wrote:\n>> I'm using a git svn tree in Cygwin. I tried doing an svn rebase and\n>> got in some weird state with local changes I can't get rid of. It's\n>> not an issue w/ the same repository on my linux machine.\n>>\n>> git reset --hard\n>> toggles 4 files between capitalization. The files don't appear to\n>> have changed case in svn, but it's a huge repository and not easy to\n>> determine with certainty.\n>\n> Try:\n> git log --name-only\n> to see which patches change which files. It's a virtual certainty\n> that they were renamed in svn at some point.\n\nThey weren't \"renamed\". Further investigation w/ the hated svn tools\nshowed that the upper case was removed, then many commits later, the\nlowercase was added.\n\n> git doesn't handle case-munging filesystems perfectly, and gets into\n> the situation you describe. First, you need to figure out whether you\n> have files with *both* cases accidentally added to your index (if git\n> reset toggles the capitalization, this is almost certainly the case):\n>\n> git ls-tree HEAD\n>\n> If you see the same files with different case, that's your problem.\n\nIndeed that was the problem. In fact, l now noticed that my linux\nmachine has both versions as well. Being case sensitive, it didn't\nmind and the problem wasn't obvious.\n\n> Now just 'git rm' the ones with the case you don't want, and commit\n> the result. (Do *not* use commit -a!) 'git status' will give you\n> some funny messages indicating that files you *didn't* 'git rm' have\n> gone away in the filesystem; it's true, of course, but don't worry\n> about that. Now 'git reset --hard HEAD' and you should be okay.\n\nThis worked fine exactly as you said. I'm curious what will happen when I do\n git svn dcommit\nThese aren't my files and I'm sort of using git svn on the sly. I'd\nprefer to not have something weird happen to the svn repository due to\nthis. Due to the schedule, our tolerance for screwing things up b/c I\nwant to use git will be low. And my argument that we should have used\ngit from the outset probably won't help any.\n\n> I'm not really sure what git should do better in this case, although\n> the current behaviour is obviously a bit confusing.\n\nYes, if SVN is going to have both versions, it's understandable that\ngit wouldn't know what to do. Unfortunately, it looks like SVN only\nhad one version at a time. So it seems git somehow revived the\nuppercase version when the lowercase one was readded through git svn.\n\nThis happened on both the cygwin and linux versions, although it only\ncaused an obvious problem on the cygwin version. I don't know git\nwell enough to speculate why this happened, but it looks like it's a\nreal bug that shouldn't have happened in this case.\n\nOn cygwin I'm using 1.5.5.1 and the repository only used that version.\nOn linux, I currently have 1.6.0.rc0.79.gb0320 but the repo may have\nbeen originally cloned w/ earlier versions.\n"},{"id":"86505","messageId":"32541b130808080740q249cb0f6t4395cc2623e67c5a@mail.gmail.com","threadId":"14863","inReplyTo":"1c5969370808071806g1f989260n55a4b8bebfedb6e@mail.gmail.com","subject":"Re: git reset --hard isn't resetting","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-08T14:40:03Z","receivedAt":"2008-08-08T14:40:03Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 7, 2008 at 9:06 PM, Matt Graham wrote:\n> On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun wrote:\n>> Try:\n>> git log --name-only\n>> to see which patches change which files. It's a virtual certainty\n>> that they were renamed in svn at some point.\n>\n> They weren't \"renamed\". Further investigation w/ the hated svn tools\n> showed that the upper case was removed, then many commits later, the\n> lowercase was added.\n\nHmm. Well, one possibly important thing is that if you take a diff\nbetween the version before the old files were removed, and the version\nafter the new files were added, it will *look* like a rename because\ngit doesn't look at the intermediate revisions. And note that this\nsort of thing will be happen if you \"git checkout\" the before and\nafter versions.\n\n> Indeed that was the problem. In fact, l now noticed that my linux\n> machine has both versions as well. Being case sensitive, it didn't\n> mind and the problem wasn't obvious.\n\nDid your Linux machine import the data using git-svn, or did it clone\na repo from Windows that imported using git-svn?\n\nI can imagine a situation where git-svn on Windows could get confused\nand add the wrong filenames (although it would be kind of unlikely if\nthey really were removed in one revision, then readded in another; why\nwould git-svn even think about the old names in that case?). However,\nthere's no explanation for a Linux system introducing such a mistake,\nsince the two files are just unrelated as far as Linux is concerned.\n\n> This worked fine exactly as you said. I'm curious what will happen when I do\n> git svn dcommit\n> These aren't my files and I'm sort of using git svn on the sly. I'd\n> prefer to not have something weird happen to the svn repository due to\n> this. Due to the schedule, our tolerance for screwing things up b/c I\n> want to use git will be low. And my argument that we should have used\n> git from the outset probably won't help any.\n\nIf your git-svn repo doesn't reflect *exactly* the set of files in\nyour real svn repo, then you've hit a pretty bad bug and you're almost\ncertainly going to have problems with dcommit. On the other hand,\nyou're unlikely to manage to screw up your svn repo, assuming the\nfiles you deleted were the ones that weren't supposed to be there;\n\"extra deleting\" them from svn wouldn't be dangerous. I'd expect git\nsvn dcommit to just fail with a weird error.\n\n>> I'm not really sure what git should do better in this case, although\n>> the current behaviour is obviously a bit confusing.\n>\n> Yes, if SVN is going to have both versions, it's understandable that\n> git wouldn't know what to do. Unfortunately, it looks like SVN only\n> had one version at a time. So it seems git somehow revived the\n> uppercase version when the lowercase one was readded through git svn.\n\nSince this seems virtually impossible, it would be nice if you could\ndouble check your SVN repo to make sure the problem really doesn't\nexist there in *any* version. It just doesn't seem likely that git\nwould have had this problem if the files were cleanly removed in one\nrevision, then added in a later one. I could imagine it if they were\nrenamed all in one revision, though, or if there was *ever* an svn\nrevision where both files existed at once. In all those cases we\neffectively have a bug in git-svn, but at least in the latter cases\nit's an explainable one :)\n\nBeware that svn doesn't reliably sort its filename lists, so you might\nfind that two different files in the *same* directory are in totally\ndifferent places in the list; perhaps you missed a filename that way.\n\nGood luck,\n\nAvery\n"},{"id":"86583","messageId":"20080809080825.GA30694@hand.yhbt.net","threadId":"14863","inReplyTo":"32541b130808080740q249cb0f6t4395cc2623e67c5a@mail.gmail.com","subject":"Re: git reset --hard isn't resetting","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-08-09T08:08:25Z","receivedAt":"2008-08-09T08:08:25Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Avery Pennarun wrote:\n> On Thu, Aug 7, 2008 at 9:06 PM, Matt Graham wrote:\n> > On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun wrote:\n> > Indeed that was the problem. In fact, l now noticed that my linux\n> > machine has both versions as well. Being case sensitive, it didn't\n> > mind and the problem wasn't obvious.\n> \n> Did your Linux machine import the data using git-svn, or did it clone\n> a repo from Windows that imported using git-svn?\n> \n> I can imagine a situation where git-svn on Windows could get confused\n> and add the wrong filenames (although it would be kind of unlikely if\n> they really were removed in one revision, then readded in another; why\n> would git-svn even think about the old names in that case?). However,\n> there's no explanation for a Linux system introducing such a mistake,\n> since the two files are just unrelated as far as Linux is concerned.\n\ngit-svn *never* touches the working tree on the filesystem directly.\nIt only does so via git-rebase or git-reset when dcommiting.\n\nThat said, I have no idea (nor interest in knowing the gory details) as\nto how/if git works on case-insensitive filesystems. git-svn certainly\nhas never done any special with them; git-svn itself will always take\npath names that SVN provides as-is.\n\n> > This worked fine exactly as you said. I'm curious what will happen when I do\n> > git svn dcommit\n> > These aren't my files and I'm sort of using git svn on the sly. I'd\n> > prefer to not have something weird happen to the svn repository due to\n> > this. Due to the schedule, our tolerance for screwing things up b/c I\n> > want to use git will be low. And my argument that we should have used\n> > git from the outset probably won't help any.\n\nMatt: try using --dry-run with dcommit to figure out what it's doing.\n\nWhenever git-svn dcommits to SVN, it reads all of its pathnames from\nalready-committed history in git, so it's unlikely to be affected\nby issues on the local filesystem. However the rebase/reset after\ndcommit could be problematic. --no-rebase can probably be used with\ndcommit here to avoid issues with rebase.\n\nThat said, I take no responsibility for any screwups that may happen.\n(especially since Windows is involved).\n\n> If your git-svn repo doesn't reflect *exactly* the set of files in\n> your real svn repo, then you've hit a pretty bad bug and you're almost\n> certainly going to have problems with dcommit. On the other hand,\n> you're unlikely to manage to screw up your svn repo, assuming the\n> files you deleted were the ones that weren't supposed to be there;\n> \"extra deleting\" them from svn wouldn't be dangerous. I'd expect git\n> svn dcommit to just fail with a weird error.\n\ngit-svn should always die/croak immediately if it notices anything\nwrong. Again, there is no guarantee nor warranty :)\n\n> >> I'm not really sure what git should do better in this case, although\n> >> the current behaviour is obviously a bit confusing.\n> >\n> > Yes, if SVN is going to have both versions, it's understandable that\n> > git wouldn't know what to do. Unfortunately, it looks like SVN only\n> > had one version at a time. So it seems git somehow revived the\n> > uppercase version when the lowercase one was readded through git svn.\n> \n> Since this seems virtually impossible, it would be nice if you could\n> double check your SVN repo to make sure the problem really doesn't\n> exist there in *any* version. It just doesn't seem likely that git\n> would have had this problem if the files were cleanly removed in one\n> revision, then added in a later one. I could imagine it if they were\n> renamed all in one revision, though, or if there was *ever* an svn\n> revision where both files existed at once. In all those cases we\n> effectively have a bug in git-svn, but at least in the latter cases\n> it's an explainable one :)\n\nOne possibility is that the SVN libraries themselves fail to report\ncase-changing renames on Windows when git-svn is fetching. And then\n(hypothetically) git on cygwin tries to do something smart somewhere\nwith case-insensitive paths.\n\nThe above is purely a hunch, anybody else want to investigate that\npossibility?\n\n-- \nEric Wong\n"}]}