{"thread":{"id":"29355","subject":"Bug? Git checkout fails with a wrong error message","startedAt":"2012-01-12T18:44:03Z","lastAt":"2012-01-19T10:24:07Z","messageCount":27,"participants":["Yves Goergen","Holger Hellmuth","Jeff King","Carlos Martín Nieto","Jakub Narebski","Thomas Rast","Erik Faye-Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182454","messageId":"loom.20120112T193624-86@post.gmane.org","threadId":"29355","inReplyTo":null,"subject":"Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-12T18:44:03Z","receivedAt":"2012-01-12T18:44:03Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"Hi,\n\nI am using Git alone for my local software project in Visual Studio 2010. I've\nbeen on the master branch most of the time. Recently I created a new branch to\ndo a larger refactoring of one of the dialogue windows. I did the following\nmodifications:\n\n* Rename Form1 to Form1a (including all depending files)\n* Add new Form1\n\nI checked this change into the branch, say form-refactoring. Interestingly, Git\ndidn't notice that I renamed the file Form1.cs into Form1a.cs and created a\nbrand new, totally different Form1.cs, but instead it noticed a new Form1a.cs\nfile and found a whole lot of differences between the previous and new Form1.cs\nfiles. This will of course lead to totally garbaged diffs, but I don't care in\nthis case as long as all files are handled correctly in the end.\n\nThen I switched back to master to do some other small changes. Nothing\nconflicting. Until now, everything worked fine.\n\nToday, I wanted to switch back to my branch form-refactoring to continue that\nwork. But all I get is the following message:\n\n-----\ngit.exe checkout form-refactoring\n\nAborting\nerror: The following untracked working tree files would be overwritten by\ncheckout:\nForm1.Designer.cs\nPlease move or remove them before you can switch branches.\n-----\n\nWhat is that supposed to be? The mentioned file is not untracked. Neither in the\nmaster branch, nor in the form-refactoring branch. It is part of both branches,\nbut one is not a descendent of the other (because it was recreated on the\nform-refactoring branch, if that matters). What would happen if I delete it, is\nit gone for good then? I don't trust Git to bring back the correct file if I\ndelete something now. I did not play with any file at all outside of my\nmentioned Git operations, so why should I play around with any file to continue\nusing Git operations now? Git broke it, Git's supposed to handle it now!\n\nHere's some other input:\n\nThere are no uncommitted changes in my working directory. 'git status' doesn't\nlist anything.\n\nThe file in question is not untracked. Right now on the master branch, it has a\ngreen checkmark in Explorer (provided by TortoiseGit) and it has a history as\nwell. There are more Form....Designer.cs files that don't cause any trouble.\n\n'git clean -f -d', 'git reset --hard HEAD', 'git stash' do nothing and don't\nhelp resolving the issue.\n\nRight now, I cannot continue with my work because I cannot switch branches. Is\nthere an easy solution to this? Is my Git repository broken, all by standard\noperations?\n"},{"id":"182494","messageId":"4F1028AD.9080701@ira.uka.de","threadId":"29355","inReplyTo":"loom.20120112T193624-86@post.gmane.org","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-01-13T12:50:53Z","receivedAt":"2012-01-13T12:50:53Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 12.01.2012 19:44, Yves Goergen wrote:\n> Hi,\n\nImportant information missing: What version of git are you using? Should \nthe version number begin with 1.6 or even lower you will get the advice \nto update your version to something non-ancient. Lots of bug-fixes \nhappened in-between.\n\n> I am using Git alone for my local software project in Visual Studio 2010. I've\n> been on the master branch most of the time. Recently I created a new branch to\n> do a larger refactoring of one of the dialogue windows. I did the following\n> modifications:\n>\n> * Rename Form1 to Form1a (including all depending files)\n> * Add new Form1\n>\n> I checked this change into the branch, say form-refactoring. Interestingly, Git\n> didn't notice that I renamed the file Form1.cs into Form1a.cs and created a\n> brand new, totally different Form1.cs, but instead it noticed a new Form1a.cs\n\nI assume .cs is a C source file for visual studio, not a generated file, \nright ?\n\n> file and found a whole lot of differences between the previous and new Form1.cs\n> files. This will of course lead to totally garbaged diffs, but I don't care in\n> this case as long as all files are handled correctly in the end.\n\ngit does not record renames like cvs/svn do. It operates on snapshots \nand infers renames through comparisions. So if the next commit has a \nfile missing and the same or similar file contents under some different \npath, it reports it as a rename. You can try -M with git log or git diff \nso that git expends more effort to detect renames+edits. Or you could \navoid doing renames and edits of the same file in the same commit.\n\nBut apart from the cosmetic inconvenience of a non-sensical diff this \ncommit wasn't more difficult or special as any other commit. git doesn't \ncare if a commit changes one line or a thousand. So I don't this \nrenaming in itself did somehow confuse git.\n\n> Then I switched back to master to do some other small changes. Nothing\n> conflicting. Until now, everything worked fine.\n >\n> Today, I wanted to switch back to my branch form-refactoring to continue that\n> work. But all I get is the following message:\n>\n> -----\n> git.exe checkout form-refactoring\n>\n> Aborting\n> error: The following untracked working tree files would be overwritten by\n> checkout:\n> Form1.Designer.cs\n> Please move or remove them before you can switch branches.\n> -----\n\nYou didn't mention that filename before (please assume people not \naccustomed to the ways of Visual Studio 2010). Is that another file you \nrenamed and created new in the form-refactoring branch?\n\nWhat does git diff -- Form1.Designer.cs' say?\nWhat does 'git diff form-refactoring -- Form1.Designer.cs' say?\n\n> What is that supposed to be? The mentioned file is not untracked. Neither in the\n> master branch, nor in the form-refactoring branch. It is part of both branches,\n> but one is not a descendent of the other (because it was recreated on the\n> form-refactoring branch, if that matters). What would happen if I delete it, is\n> it gone for good then? I don't trust Git to bring back the correct file if I\n\nYou can copy the file to somewhere outside of git and do 'git checkout \n-- Form1.Designer.cs'. A comparision of the two files should show you \nthat git still has the files recorded.\n\n> Right now, I cannot continue with my work because I cannot switch branches. Is\n> there an easy solution to this? Is my Git repository broken, all by standard\n> operations?\n\nThe easy solution is: Make a backup of the repository, then 'git \ncheckout -f form-refactoring'. My uneducated guess is that the problem \nhas to do with an old git version and white space or filenames with \ndifferent case on a case-insensitive file system or some other problem \nthat leads to a misinterpretation. But as I said, uneducated guess!\n"},{"id":"182504","messageId":"loom.20120113T181805-423@post.gmane.org","threadId":"29355","inReplyTo":"loom.20120112T193624-86@post.gmane.org","subject":"Bug! Git merge also fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-13T17:37:38Z","receivedAt":"2012-01-13T17:37:38Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"I have updates to this issue.\n\nAfter asking several people who didn't believe me,\nafter all I could pass all checks to ensure that\nthe file in question really is tracked, despite the error\nmessage telling it is not. (The file has a history, it is\npart of the branch,\ngit status behaves as expected when I rename it, and so on.)\n\nI had found a workaround hack to access my\ndata again: I have cloned the repo\ninto another directory, then switched to\nthe branch in there (it actually\nworked) and used BeyondCompare to manually(!)\nswitch my original repo and\nworking directory by copying some (not all) files\nin .git and all differences in\nthe working directory.\n\nThat worked fine at first, I could commit to that branch.\n\nToday I wanted to merge that branch into master again.\nSwitching to master was\nfine, but merging from the form-refactoring branch\nnow fails for the very same\n\"reason\":\n\n-----\ngit.exe merge --no-commit form-refactoring\n\nerror: The following untracked working tree files\nwould be overwritten by merge:\nForm1.Designer.cs\nPlease move or remove them before you can merge.\nAborting\n-----\n\nAgain, that file is NOT untracked. Git just fails\nprocessing its own data. I\ncannot move that file because it is part of the\nother branch and must be merged now.\n\nAm I now supposed to checkout both branches and\ndo the merge somehow on my own?\n\nMaybe it's not a good idea to use branching and\nthen rename, create and delete\nfiles on that branch, as switching and merging\nfail completely afterwards. And\nin the end, maybe Git isn't all that good and\nsome of the alternatives with real\nfile tracking should be preferred.\n\nI, for one, have lost a great amount of trust\nin Git in the last two days.\n\n(Sorry for the formatting mess, but the stupid Gmane\npost editor forced me to do that or it wouldn't\naccept my message... Don't you have a real mailing\nlist, if there's no web forum??)\n"},{"id":"182507","messageId":"4F106DDF.4040408@unclassified.de","threadId":"29355","inReplyTo":"4F1028AD.9080701@ira.uka.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-13T17:46:07Z","receivedAt":"2012-01-13T17:46:07Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:\n> Important information missing: What version of git are you using? Should \n> the version number begin with 1.6 or even lower you will get the advice \n> to update your version to something non-ancient. Lots of bug-fixes \n> happened in-between.\n\nThe first bug happened with msysGit 1.7.6 and 1.7.8, the second one\n(reported now) with 1.7.8. That update didn't change a thing.\n\n> I assume .cs is a C source file for visual studio, not a generated file, \n> right ?\n\n.cs is C# code and .Designer.cs files are used internally by the Visual\nStudio designer. They're not supposed to be edited by the programmer and\ncontain lots of stuff that changes all the time. So they are generated\nand presented in a different way.\n\n> git does not record renames like cvs/svn do. It operates on snapshots \n> and infers renames through comparisions. So if the next commit has a \n> file missing and the same or similar file contents under some different \n> path, it reports it as a rename. You can try -M with git log or git diff \n> so that git expends more effort to detect renames+edits. Or you could \n> avoid doing renames and edits of the same file in the same commit.\n\nI renamed the file and created a new one with the same name. Is it so\nsimple to crash the Git repository?\n\n>> -----\n>> git.exe checkout form-refactoring\n>>\n>> Aborting\n>> error: The following untracked working tree files would be overwritten by\n>> checkout:\n>> Form1.Designer.cs\n>> Please move or remove them before you can switch branches.\n>> -----\n> \n> You didn't mention that filename before (please assume people not \n> accustomed to the ways of Visual Studio 2010). Is that another file you \n> renamed and created new in the form-refactoring branch?\n\nForm1.cs, Form1.Designer.cs and Form1.resx all belong together and are\nrenamed atomically. If I rename \"Form1\" in the project, actually these 3\nfiles are renamed on disk.\n\n> What does git diff -- Form1.Designer.cs' say?\n\nNothing.\n\n> What does 'git diff form-refactoring -- Form1.Designer.cs' say?\n\nAll lines deleted.\n\nWill this message also appear on the mailing list where I posted my\nfirst message with Gmane? (That's the only thing I've found on the\nofficial Git website.)\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182505","messageId":"20120113175040.GC9373@sigill.intra.peff.net","threadId":"29355","inReplyTo":"loom.20120113T181805-423@post.gmane.org","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-13T17:50:40Z","receivedAt":"2012-01-13T17:50:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:\n\n> After asking several people who didn't believe me,\n> after all I could pass all checks to ensure that\n> the file in question really is tracked, despite the error\n> message telling it is not. (The file has a history, it is\n> part of the branch,\n> git status behaves as expected when I rename it, and so on.)\n\nWhether a file in the working tree is tracked or not does not have to do\nwith the history, but rather with whether it is mentioned in the index.\n\nDoes the file appear in \"git ls-files\"?\n\nIt sounds like you are perhaps making changes in the working tree and\nindex, and then trying to checkout/merge on top of that. In that case\n\"git status\" would report the file as renamed, but it's possible the\nfile is still in the working tree. From git's perspective the file is no\nlonger tracked, but the operations you are requesting would overwrite\nthe new contents (and git is being safe by refusing to do so).\n\nGenerally you don't want to merge with uncommitted changes like this.\nYou would want to commit them and then do your merge.\n\nBut even if you do commit, the question still remains: if you have\ncommitted the removal of this file, then why is it still there? Is\nsomething else creating it after you have deleted it?\n\n-Peff\n"},{"id":"182506","messageId":"20120113175617.GE2850@centaur.lab.cmartin.tk","threadId":"29355","inReplyTo":"loom.20120113T181805-423@post.gmane.org","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-01-13T17:56:17Z","receivedAt":"2012-01-13T17:56:17Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:\n> I have updates to this issue.\n\nYou still haven't told us what version of (msys)git you're using nor\nhave you provided a transcript of your session or found a minimal\nreproducible example.\n\nGmane is a mailing list viewer and there /only/ is the real maling\nlist. The e-mail you provided for yourself looks bogus, but if it\nisn't, you'll notice we communicate via e-mail.\n\n> \n> After asking several people who didn't believe me,\n> after all I could pass all checks to ensure that\n> the file in question really is tracked, despite the error\n> message telling it is not. (The file has a history, it is\n> part of the branch,\n> git status behaves as expected when I rename it, and so on.)\n> \n> I had found a workaround hack to access my\n> data again: I have cloned the repo\n> into another directory, then switched to\n> the branch in there (it actually\n> worked) and used BeyondCompare to manually(!)\n> switch my original repo and\n> working directory by copying some (not all) files\n> in .git and all differences in\n> the working directory.\n> \n> That worked fine at first, I could commit to that branch.\n> \n> Today I wanted to merge that branch into master again.\n> Switching to master was\n> fine, but merging from the form-refactoring branch\n> now fails for the very same\n> \"reason\":\n> \n> -----\n> git.exe merge --no-commit form-refactoring\n> \n> error: The following untracked working tree files\n> would be overwritten by merge:\n> Form1.Designer.cs\n> Please move or remove them before you can merge.\n> Aborting\n> -----\n> \n> Again, that file is NOT untracked. Git just fails\n> processing its own data. I\n> cannot move that file because it is part of the\n> other branch and must be merged now.\n> \n> Am I now supposed to checkout both branches and\n> do the merge somehow on my own?\n> \n> Maybe it's not a good idea to use branching and\n> then rename, create and delete\n> files on that branch, as switching and merging\n> fail completely afterwards. And\n> in the end, maybe Git isn't all that good and\n> some of the alternatives with real\n> file tracking should be preferred.\n> \n> I, for one, have lost a great amount of trust\n> in Git in the last two days.\n> \n> (Sorry for the formatting mess, but the stupid Gmane\n> post editor forced me to do that or it wouldn't\n> accept my message... Don't you have a real mailing\n> list, if there's no web forum??)\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n-- \nCarlos Martín Nieto | http://cmartin.tk\n\n\"¿Cómo voy a decir bobadas si soy mudo?\" -- CACHAI\n"},{"id":"182508","messageId":"4F107CAD.1020103@unclassified.de","threadId":"29355","inReplyTo":"20120113175040.GC9373@sigill.intra.peff.net","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-13T18:49:17Z","receivedAt":"2012-01-13T18:49:17Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 18:50 CE(S)T, Jeff King wrote:\n> Whether a file in the working tree is tracked or not does not have to do\n> with the history, but rather with whether it is mentioned in the index.\n\nI'm not using the index. In fact I don't even know how that what I have\nread about it can be useful.\n\n> Does the file appear in \"git ls-files\"?\n\nYes, it's in the list along with all other files.\n\n> It sounds like you are perhaps making changes in the working tree and\n> index, and then trying to checkout/merge on top of that. In that case\n> \"git status\" would report the file as renamed, but it's possible the\n> file is still in the working tree. From git's perspective the file is no\n> longer tracked, but the operations you are requesting would overwrite\n> the new contents (and git is being safe by refusing to do so).\n\nHere's the git status output:\n# On branch master\nnothing to commit (working directory clean)\n\nI have switched to master and the very next action was trying the merge.\nThere's no change in the working directory, and nothing uncommitted.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182509","messageId":"20120113185436.GA13522@sigill.intra.peff.net","threadId":"29355","inReplyTo":"4F107CAD.1020103@unclassified.de","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-13T18:54:36Z","receivedAt":"2012-01-13T18:54:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 13, 2012 at 07:49:17PM +0100, Yves Goergen wrote:\n\n> On 13.01.2012 18:50 CE(S)T, Jeff King wrote:\n> > Whether a file in the working tree is tracked or not does not have to do\n> > with the history, but rather with whether it is mentioned in the index.\n> \n> I'm not using the index. In fact I don't even know how that what I have\n> read about it can be useful.\n\nWhether you realize it or not, git is using the index to store state.\nWhen you \"git add\", \"git rm\", or \"git mv\", it is updating the index.\n\n> > Does the file appear in \"git ls-files\"?\n> \n> Yes, it's in the list along with all other files.\n\nThen it should be considered tracked, and there's a bug.\n\nI notice that in your first mail, you mentioned a problem with\n\"checkout\", and in the second one, a problem with \"merge\". Do you still\nhave the repo around with the \"checkout\" problem? If so, is the file\nalso in your \"git ls-files\" output in that repo?\n\nIt is much more likely to me that there is a bug in the merge than in\nregular checkout (because merge has many complex corner cases\nsurrounding the 3-way merge, whereas checkout is simply moving from one\nstate to another). I'd like to make sure we're not seeing two different\nproblems.\n\n> Here's the git status output:\n> # On branch master\n> nothing to commit (working directory clean)\n> \n> I have switched to master and the very next action was trying the merge.\n> There's no change in the working directory, and nothing uncommitted.\n\nWhich version of git are you using? There were many bugs fixed around\nthis area of merge around the v1.7.7 timeframe.\n\n-Peff\n"},{"id":"182511","messageId":"4F107F16.30009@unclassified.de","threadId":"29355","inReplyTo":"20120113175617.GE2850@centaur.lab.cmartin.tk","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-13T18:59:34Z","receivedAt":"2012-01-13T18:59:34Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:\n> You still haven't told us what version of (msys)git you're using nor\n> have you provided a transcript of your session or found a minimal\n> reproducible example.\n\nIn case one of my other mails didn't arrive, the Git version is 1.7.8.\n\nThere is no session transcript because I use TortoiseGit and I'm not\ngoing to add a screencast here.\n\n> Gmane is a mailing list viewer and there /only/ is the real maling\n> list. The e-mail you provided for yourself looks bogus, but if it\n> isn't, you'll notice we communicate via e-mail.\n\nWell, I am very confused. Starting from git-scm.com, the only support\nsite is a mailing list, and the hyperlink on that word sends me to Gmane\nwhich says I am in a newsgroup called \"gmane.comp.version-control.git\".\nSince I don't have access to the news system, I need to use the Gmane\nwebsite. I don't know exactly what it is. I know mailing lists, but that\ndoesn't look like one at all. There's not even a subscription page or\naddress. For users of the modern web who are not familiar with 70s nntp\ntechnology and cannot use a mailing list by merely knowing its address,\nthis is very support-unfriendly. I almost would have considered that the\nofficial Git website doesn't want to offer any support at all. In that\ncase I would likely have searched for an alternative and switched right\naway. Assuming I could have extracted the remainders of my source code\nfrom the broken Git repository.\n\nSo am I now subscribed to that \"git@vger.kernel.org\" mailing list and do\nmy posts show up there? I have no idea what's going on, neither in my\nrepository, nor in this mailing list. Confusing and intransparent.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182512","messageId":"4F108094.5080705@unclassified.de","threadId":"29355","inReplyTo":"20120113185436.GA13522@sigill.intra.peff.net","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-13T19:05:56Z","receivedAt":"2012-01-13T19:05:56Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 19:54 CE(S)T, Jeff King wrote:\n> Whether you realize it or not, git is using the index to store state.\n> When you \"git add\", \"git rm\", or \"git mv\", it is updating the index.\n\nI'm using TortoiseGit most of the time and that doesn't expose the\nconcept of an \"index\". I edit files as usual, then select \"commit\" and\nget the commit dialogue. In there I enter the commit message and select\nall files to commit. I can add new files right there. There is no\ntwo-step procedure.\n\n> I notice that in your first mail, you mentioned a problem with\n> \"checkout\", and in the second one, a problem with \"merge\". Do you still\n> have the repo around with the \"checkout\" problem? If so, is the file\n> also in your \"git ls-files\" output in that repo?\n\nYes, I have made a backup of the repo right after the initial problem\narose. And the git ls-files output is the same regarding that file.\n\n> Which version of git are you using? There were many bugs fixed around\n> this area of merge around the v1.7.7 timeframe.\n\nmsysGit 1.7.8 on Windows XP SP3. It's a \"preview\" but since Git is so\nold now and there's been nothing but \"previews\", I consider msysGit's\nmeaning of the word \"preview\" as \"stable\".\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182516","messageId":"4F1085EC.9010708@ira.uka.de","threadId":"29355","inReplyTo":"4F106DDF.4040408@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-01-13T19:28:44Z","receivedAt":"2012-01-13T19:28:44Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Added Peff and Carlos to the CC so they see this part of the thread too.\n\nOn 13.01.2012 18:46, Yves Goergen wrote:\n> On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:\n>> Important information missing: What version of git are you using? Should\n>> the version number begin with 1.6 or even lower you will get the advice\n>> to update your version to something non-ancient. Lots of bug-fixes\n>> happened in-between.\n>\n> The first bug happened with msysGit 1.7.6 and 1.7.8, the second one\n> (reported now) with 1.7.8. That update didn't change a thing.\n>\n>> I assume .cs is a C source file for visual studio, not a generated file,\n>> right ?\n>\n> .cs is C# code and .Designer.cs files are used internally by the Visual\n> Studio designer. They're not supposed to be edited by the programmer and\n> contain lots of stuff that changes all the time. So they are generated\n> and presented in a different way.\n\nIs it possible that Visual Studio changes them while you are comitting?\n\n>> git does not record renames like cvs/svn do. It operates on snapshots\n>> and infers renames through comparisions. So if the next commit has a\n>> file missing and the same or similar file contents under some different\n>> path, it reports it as a rename. You can try -M with git log or git diff\n>> so that git expends more effort to detect renames+edits. Or you could\n>> avoid doing renames and edits of the same file in the same commit.\n>\n> I renamed the file and created a new one with the same name. Is it so\n> simple to crash the Git repository?\n\nWho said anything about crash? git simply doesn't care whether a change \nis because of a rename. It isn't special or different to any change you \ncan make to a file\n\n\n>>> -----\n>>> git.exe checkout form-refactoring\n>>>\n>>> Aborting\n>>> error: The following untracked working tree files would be overwritten by\n>>> checkout:\n>>> Form1.Designer.cs\n>>> Please move or remove them before you can switch branches.\n>>> -----\n>>\n>> You didn't mention that filename before (please assume people not\n>> accustomed to the ways of Visual Studio 2010). Is that another file you\n>> renamed and created new in the form-refactoring branch?\n>\n> Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are\n> renamed atomically. If I rename \"Form1\" in the project, actually these 3\n> files are renamed on disk.\n\nAs an aside, if .Designer.cs is generated automatically from Form1.cs it \nshouldn't be tracked at all. Maybe tortoise git has a global gitignore \nwith a line \"*.Designer.cs\" in it to account for that fact. Maybe this \nlead to the error message?\n\n>> What does git diff -- Form1.Designer.cs' say?\n>\n> Nothing.\n>\n>> What does 'git diff form-refactoring -- Form1.Designer.cs' say?\n>\n> All lines deleted.\n\nReally all lines? That would indicate that you don't have a file \nForm1.Designer.cs (or an empty one) in your working directory in branch \nmaster. In case there is no file (as seen by git) the output of diff \nshould compare with /dev/null aka the void aka . Also notice the line \"deleted file mode ...\"\n\n > git diff master -- zumf\ndiff --git a/zumf b/zumf\ndeleted file mode 100644\nindex 925eccd..0000000\n--- a/zumf\n+++ /dev/null\n@@ -1 +0,0 @@\n\nOr did you just mean \"all the shown lines in the diff were fronted by a \nminus sign\"? Which would just indicate that the file in form-refactoring \nis a superset of the one in master.\n\n(As you can see, actual reproduction of command line output is very \nhelpful to avoid ambiguity and can give further hints)\n"},{"id":"182517","messageId":"m3mx9re6t0.fsf@localhost.localdomain","threadId":"29355","inReplyTo":"4F107F16.30009@unclassified.de","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-13T19:34:29Z","receivedAt":"2012-01-13T19:34:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yves Goergen writes:\n> On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:\n \n> > Gmane is a mailing list viewer and there /only/ is the real maling\n> > list. The e-mail you provided for yourself looks bogus, but if it\n> > isn't, you'll notice we communicate via e-mail.\n> \n> Well, I am very confused. Starting from git-scm.com, the only support\n> site is a mailing list, and the hyperlink on that word sends me to Gmane\n> which says I am in a newsgroup called \"gmane.comp.version-control.git\".\n\nNote however that the _text_ of the hyperlink is\n\n git@vger.kernel.org mailing list\n\n> Since I don't have access to the news system, I need to use the Gmane\n> website. I don't know exactly what it is.\n\nGMane is an e-mail to news gateway, and a mailing list archive. It\nexposes mailing list as a newsgroup, so it can be read and written to\nvia newsreader (via Usenet).\n\nPerhaps better solution would be to use mailto:git@vger.kernel.org\nlink, and add a sentence about archives / alternative interfaces.\n\n> I know mailing lists, but that\n> doesn't look like one at all. There's not even a subscription page or\n> address. \n\ngit@vger.kernel.org is a public non-subscribe mailing list; you don't\nneed to subscribe to post requests there. Note that it is a custom on\nthis mailing list to always include all participants in given\n(sub)thread directly in Cc, so you should get responses to your emails\neven if you are not subscribed.\n\n[...]\n> So am I now subscribed to that \"git@vger.kernel.org\" mailing list and do\n> my posts show up there? I have no idea what's going on, neither in my\n> repository, nor in this mailing list. Confusing and non-transparent.\n\nIf you send email to git@vger.kernel.org, it would also appear on\nGMane.\n\n-- \nJakub Narebski\n"},{"id":"182574","messageId":"4F128AD0.5020101@unclassified.de","threadId":"29355","inReplyTo":"4F1085EC.9010708@ira.uka.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-15T08:14:08Z","receivedAt":"2012-01-15T08:14:08Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 20:28 CE(S)T, Holger Hellmuth wrote:\n> Is it possible that Visual Studio changes them while you are comitting?\n\nNo. Those files may only be modified while open.\n\n>> I renamed the file and created a new one with the same name. Is it so\n>> simple to crash the Git repository?\n> \n> Who said anything about crash? git simply doesn't care whether a change \n> is because of a rename. It isn't special or different to any change you \n> can make to a file\n\nWell, there is a tracked file about which Git says it's untracked. How\nwould you describe such internal inconsistency? Maybe corruption would\nfit better.\n\n> As an aside, if .Designer.cs is generated automatically from Form1.cs it \n> shouldn't be tracked at all.\n\nOf course, it's important! The file contains everything I draw in the UI\ndesigner. I just don't write that myself which is why I rarely see its\ncontents.\n\n> Maybe tortoise git has a global gitignore \n> with a line \"*.Designer.cs\" in it to account for that fact. Maybe this \n> lead to the error message?\n\nIt hasn't. This is already triple-checked by now. The file really is\ndefinitely not ignored by any of the both ignore/exclude files known to me.\n\n>>> What does git diff -- Form1.Designer.cs' say?\n>> Nothing.\n>>\n>>> What does 'git diff form-refactoring -- Form1.Designer.cs' say?\n>> All lines deleted.\n> \n> Really all lines?\n\nI don't have the time to re-check right now, but I remember seeing a\nvalid file beginning and end and no gaps in between. So I think it was\nall files.\n\n> That would indicate that you don't have a file \n> Form1.Designer.cs (or an empty one) in your working directory in branch \n> master. In case there is no file (as seen by git) the output of diff \n> should compare with /dev/null aka the void aka prints on the windows side>. Also notice the line \"deleted file mode ...\"\n> \n> > git diff master -- zumf\n> diff --git a/zumf b/zumf\n> deleted file mode 100644\n> index 925eccd..0000000\n> --- a/zumf\n> +++ /dev/null\n> @@ -1 +0,0 @@\n> \n> Or did you just mean \"all the shown lines in the diff were fronted by a \n> minus sign\"?\n\nYes, and in dark red.\n\n> Which would just indicate that the file in form-refactoring \n> is a superset of the one in master.\n> \n> (As you can see, actual reproduction of command line output is very \n> helpful to avoid ambiguity and can give further hints)\n\nThat was some kind of less display. I could have attached a screenshot\nto show it. It's not common or especially simple to include console\noutput on Windows, as there often is no console at all.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182575","messageId":"4F128B81.2000502@unclassified.de","threadId":"29355","inReplyTo":"m3mx9re6t0.fsf@localhost.localdomain","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-15T08:17:05Z","receivedAt":"2012-01-15T08:17:05Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 13.01.2012 20:34 CE(S)T, Jakub Narebski wrote:\n>> Since I don't have access to the news system, I need to use the Gmane\n>> website. I don't know exactly what it is.\n> \n> GMane is an e-mail to news gateway, and a mailing list archive. It\n> exposes mailing list as a newsgroup, so it can be read and written to\n> via newsreader (via Usenet).\n\nI have Thunderbird, but I have no usenet server to entry in a usenet\naccount, so as I said, I don't have access to that part of the internet.\nI had at university, but that's some time ago now.\n\n> git@vger.kernel.org is a public non-subscribe mailing list; you don't\n> need to subscribe to post requests there. Note that it is a custom on\n> this mailing list to always include all participants in given\n> (sub)thread directly in Cc, so you should get responses to your emails\n> even if you are not subscribed.\n\nGood to know NOW. It really should have informed me in the first place\non that website. It's a vital information without which you likely won't\nget anywhere (as I).\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182581","messageId":"201201151108.39335.jnareb@gmail.com","threadId":"29355","inReplyTo":"4F128B81.2000502@unclassified.de","subject":"Re: Bug! Git merge also fails with a wrong error message","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-15T10:08:38Z","receivedAt":"2012-01-15T10:08:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 15 Jan 2012, Yves Goergen wrote:\n> On 13.01.2012 20:34 CE(S)T, Jakub Narebski wrote:\n\n> > > Since I don't have access to the news system, I need to use the Gmane\n> > > website. I don't know exactly what it is.\n> > \n> > GMane is an e-mail to news gateway, and a mailing list archive. It\n> > exposes mailing list as a newsgroup, so it can be read and written to\n> > via newsreader (via Usenet).\n> \n> I have Thunderbird, but I have no usenet server to entry in a usenet\n> account, so as I said, I don't have access to that part of the internet.\n> I had at university, but that's some time ago now.\n\nGMane serves as a Usenet server; that is how it works as mail to news\ngateway. The server name is news.gmane.org... or you can try using the\nfollowing URL\n\n nntp://news.gmane.org/gmane.comp.version-control.git\n \n> > git@vger.kernel.org is a public non-subscribe mailing list; you don't\n> > need to subscribe to post requests there. Note that it is a custom on\n> > this mailing list to always include all participants in given\n> > (sub)thread directly in Cc, so you should get responses to your emails\n> > even if you are not subscribed.\n> \n> Good to know NOW. It really should have informed me in the first place\n> on that website. It's a vital information without which you likely won't\n> get anywhere (as I).\n\nYou can get this information on GitCommunity page on Git Wiki. For the\ntime being (while Git Wiki is served as set of static pages of exported\ncontents because of lack of hardware) you can find it here:\n\n https://git.wiki.kernel.org/articles/g/i/t/GitCommunity_c4e3.html\n\n-- \nJakub Narebski\nPoland\n"},{"id":"182612","messageId":"4F1404E7.9040805@ira.uka.de","threadId":"29355","inReplyTo":"4F128AD0.5020101@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-01-16T11:07:19Z","receivedAt":"2012-01-16T11:07:19Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 15.01.2012 09:14, Yves Goergen wrote:\n> On 13.01.2012 20:28 CE(S)T, Holger Hellmuth wrote:\n>> Is it possible that Visual Studio changes them while you are comitting?\n>\n> No. Those files may only be modified while open.\n>\n>>> I renamed the file and created a new one with the same name. Is it so\n>>> simple to crash the Git repository?\n>>\n>> Who said anything about crash? git simply doesn't care whether a change\n>> is because of a rename. It isn't special or different to any change you\n>> can make to a file\n>\n> Well, there is a tracked file about which Git says it's untracked. How\n> would you describe such internal inconsistency? Maybe corruption would\n> fit better.\n\nThe original point I was trying to make was that git rename is made out \nof the rather simple operations git add and git rm . \nNot a seldom used function but the basic operations of the vcs. It must \nbe one heck of a corner case or a bit flip in the hardware.\n\nThe most likely place where the corruption could be is the index. This \nis actually a simple file located in .git\\ that can be recreated by \ndeleting that file and doing \"git reset\". I would shut down tortoise-git \n(i.e. the explorer) before doing this and use the command line.\n"},{"id":"182618","messageId":"4F14718B.80209@unclassified.de","threadId":"29355","inReplyTo":"4F1404E7.9040805@ira.uka.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-16T18:50:51Z","receivedAt":"2012-01-16T18:50:51Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"It's getting more weird. I believe that (msys)Git doesn't really know\nhow the filesystem on its operating system works. I have made some more\nchanges now and want to commit them. TortoiseGit reports the files\nForm1.Designer.cs and Form1.designer.cs (note the case difference) as\nmodified and ready to commit. How is that supposed to work? On Windows,\nfile names are case-insensitive (as on MacOS X) and both names refer to\nthe absolute same file. 'git status' has the very same listing with that\nsame file twice.\n\nWhat else is now broken in my repository?\n\nIf the index is such a problem child, how can I safely delete it\ncompletely and maybe have it regenerated if Git can't live without it?\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182621","messageId":"4F14736F.6040903@unclassified.de","threadId":"29355","inReplyTo":"4F1404E7.9040805@ira.uka.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-16T18:58:55Z","receivedAt":"2012-01-16T18:58:55Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"Great, I have the same file with an equal name twice in my repository\n(with 'git ls-files').\n\nHow stupid! Git, go learn file names.\n\nI've read (and seen) bad things about Git and Windows, and I knew the\nGreat Failure Day would eventually come. And I've read that Mercurial\nwould be better suitable for Windows. You don't know anything about\nthat, do you?\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182623","messageId":"20120116190956.GA13802@sigill.intra.peff.net","threadId":"29355","inReplyTo":"4F14718B.80209@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-16T19:09:56Z","receivedAt":"2012-01-16T19:09:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 16, 2012 at 07:50:51PM +0100, Yves Goergen wrote:\n\n> It's getting more weird. I believe that (msys)Git doesn't really know\n> how the filesystem on its operating system works. I have made some more\n> changes now and want to commit them. TortoiseGit reports the files\n> Form1.Designer.cs and Form1.designer.cs (note the case difference) as\n> modified and ready to commit. How is that supposed to work? On Windows,\n> file names are case-insensitive (as on MacOS X) and both names refer to\n> the absolute same file. 'git status' has the very same listing with that\n> same file twice.\n\nWhat is the output of \"git config core.ignorecase\" in your repository?\n\n> If the index is such a problem child, how can I safely delete it\n> completely and maybe have it regenerated if Git can't live without it?\n\nIf you delete your index, it will appear to git as if you have staged\nall files for deletion (if you run \"git status\", for example). You can\nthen run \"git reset\" to regenerate it based on the last commit.\n\nBut I doubt that will help your problem. It seems unlikely to me that\nthe source of the problem is a corrupted index, but rather is some\ncorner case in case-insensitive comparisons between the index and the\nworking tree.\n\n-Peff\n"},{"id":"182626","messageId":"87r4yzzcci.fsf@thomas.inf.ethz.ch","threadId":"29355","inReplyTo":"4F14718B.80209@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-16T19:17:17Z","receivedAt":"2012-01-16T19:17:17Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Yves Goergen writes:\n\n> It's getting more weird. I believe that (msys)Git doesn't really know\n> how the filesystem on its operating system works. I have made some more\n> changes now and want to commit them. TortoiseGit reports the files\n> Form1.Designer.cs and Form1.designer.cs (note the case difference) as\n> modified and ready to commit. How is that supposed to work?\n\nDepends.\n\nIf you work together with developers who have a case-sensitive FS (such\nas Linux, or with the right options OS X), it's entirely possible that\nthis file exists in both spellings within the repository.\n\nOtherwise, because Git needs to have the ability to store such\nspellings, there are some ways of introducing them (e.g.,\ngit-update-index).\n\nI suspect the adoption rate of TortoiseGit across this list is about 0%,\npartly because it is a Windows-only tool, partly because it was written\nalmost entirely without interacting with the Git list. So speaking in\nTortoiseGit terms here will most likely get you nowhere.\n\n> If the index is such a problem child, how can I safely delete it\n> completely and maybe have it regenerated if Git can't live without it?\n\nThe index is not only, as its name might imply, a throw-away cache. It\nis also used as the area where you prepare the contents of the next\ncommit, and thus might hold data you do not want to lose. Nevertheless,\nyou can discard and reset it to the contents of HEAD with\n\n rm -f .git/index\n git reset\n\n> Great, I have the same file with an equal name twice in my repository\n> (with 'git ls-files').\n> \n> How stupid! Git, go learn file names.\n\nPlease cut&paste (!) actual command invocations (!) and outputs.\n\nTo see why this is important, consider\n\n \"I have the same file with an equal name twice in my repository\"\n\nJudging by how this thread is going, there are at least four ways this\ncould be interpreted:\n\n* You have the byte-for-byte identical file name listed twice in the\n index. That would be a pretty bad bug.\n\n* Ditto, but in a commit.\n\n* You have two filenames in the index that differ only by case, which\n makes them identical to your OS.\n\n* Ditto, but in a commit.\n\nSee what I mean?\n\nSo please, let's be precise. You could start by cut&pasting the outputs\nof the following commands:\n\n git ls-tree -r HEAD\n git ls-files --debug\n git status -s\n\nOtherwise, you can keep throwing around fuzzy complaints all you want\nbut nobody will be able to help you because we cannot determine the\nexact state that your repository is in.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182633","messageId":"CABPQNSYjYUWdOm2uK5au_gBi8eYmo5q0e1g52nZoRqrC2TF9TA@mail.gmail.com","threadId":"29355","inReplyTo":"4F14718B.80209@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-01-16T21:18:39Z","receivedAt":"2012-01-16T21:18:39Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Jan 16, 2012 at 7:50 PM, Yves Goergen\n wrote:\n> It's getting more weird. I believe that (msys)Git doesn't really know\n> how the filesystem on its operating system works.\n\nGit for Windows know how the file-system works, and tries to prevent\nyou from shooting yourself in the leg by being case-insensitive when\nmatching the index and the working copy. But there is an opt-out for\nthis, which is controlled by the configuration option core.ignorecase,\nwhich Peff already asked about. This option is supposed to be enabled\nby default on Windows.\n\nWhat you are describing sounds like that option might have gotten\ndisabled somehow. But it might be something else, see below.\n\n> I have made some more\n> changes now and want to commit them. TortoiseGit reports the files\n> Form1.Designer.cs and Form1.designer.cs (note the case difference) as\n> modified and ready to commit. How is that supposed to work?\n\nVery speculative comment: This might be a bug in TortoiseGit. Looking\nat the sources, it seems they are using libgit2 to mess around with\nthe index; perhaps it's case-sensitivity code isn't as well tested as\nGit for Windows'?\n\nFor instance, they do their own index and tree sorting, in an attempt\nto be case sensitive:\n\nhttp://code.google.com/p/tortoisegit/source/diff?spec=svnf151c0ddf205fa1fc1ff886b8cfc4af87d373b26&r=f151c0ddf205fa1fc1ff886b8cfc4af87d373b26&format=side&path=/src/Git/GitIndex.cpp\n"},{"id":"182635","messageId":"4F1494AA.1000004@unclassified.de","threadId":"29355","inReplyTo":"20120116190956.GA13802@sigill.intra.peff.net","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-16T21:20:42Z","receivedAt":"2012-01-16T21:20:42Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 16.01.2012 20:09 CE(S)T, Jeff King wrote:\n> What is the output of \"git config core.ignorecase\" in your repository?\n\nNone, i.e. an empty line.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182636","messageId":"20120116212709.GA21770@sigill.intra.peff.net","threadId":"29355","inReplyTo":"4F1494AA.1000004@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-16T21:27:09Z","receivedAt":"2012-01-16T21:27:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:\n\n> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:\n> > What is the output of \"git config core.ignorecase\" in your repository?\n> \n> None, i.e. an empty line.\n\nThat's odd. When the repository is first created, git will do a test to\nsee whether the filesystem supports case-sensitivity, and will set\ncore.ignorecase if it does not. Might this repository have been created\non a different filesystem, and then moved onto the case-insensitive\nfilesystem?\n\nOr might it have been created by something other than core git? I don't\nknow whether one can create a repo in TortoiseGit, or if so how it does\nso.\n\nIn any case, try doing:\n\n git config core.ignorecase true\n\nand see if that clears up your problems.\n\n-Peff\n"},{"id":"182676","messageId":"4F152639.9010505@unclassified.de","threadId":"29355","inReplyTo":"20120116212709.GA21770@sigill.intra.peff.net","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-17T07:41:45Z","receivedAt":"2012-01-17T07:41:45Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 16.01.2012 22:27 CE(S)T, Jeff King wrote:\n> On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:\n> \n>> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:\n>>> What is the output of \"git config core.ignorecase\" in your repository?\n>> None, i.e. an empty line.\n> \n> That's odd. When the repository is first created, git will do a test to\n> see whether the filesystem supports case-sensitivity, and will set\n> core.ignorecase if it does not. Might this repository have been created\n> on a different filesystem, and then moved onto the case-insensitive\n> filesystem?\n> \n> Or might it have been created by something other than core git? I don't\n> know whether one can create a repo in TortoiseGit, or if so how it does\n> so.\n\nIt may have been created through the Visual Studio source provider for\nGit, which is configured to use TortoiseGit which in turn uses msysGit.\nBut I have not written any of those programmes so I cannot guarantee for\nwhat they do.\n\n> In any case, try doing:\n> \n> git config core.ignorecase true\n> \n> and see if that clears up your problems.\n\n'git config core.ignorecase' now outputs \"true\" but I can still commit\nthe same file (modified) twice. So this doesn't help.\n\nMeanwhile I have browsed my other code projects and found that the\ndesigner-generated file name is sometimes with a \"D\" and sometimes with\na \"d\", so it's usually inconsistent. I haven't figured out where that\ncomes from but it means that this is a common issue that Git needs to\nhandle well to be usable on Windows. But we're not there yet.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182679","messageId":"87ipkaogyj.fsf@thomas.inf.ethz.ch","threadId":"29355","inReplyTo":"4F152767.9010104@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-17T08:45:24Z","receivedAt":"2012-01-17T08:45:24Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Yves Goergen writes:\n\n> On 16.01.2012 20:17 CE(S)T, Thomas Rast wrote:\n>> If you work together with developers who have a case-sensitive FS (such\n>> as Linux, or with the right options OS X), it's entirely possible that\n>> this file exists in both spellings within the repository.\n>\n> Just FTR, I am working on the project alone, only on Windows with Visual\n> Studio 2010 and I have two copies of the repository which I am\n> occasionally synchronising via a USB memory stick when I work on the\n> other machine. I have not pulled anything since the first issue came up\n> on last Friday. No case-sensitive filesystem in the game.\n\nOk.\n\n $ git ls-tree -r HEAD\n 100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.Designer.cs\n 100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.designer.cs\n ^ ^ ^\n | | content hash\n | type\n file mode\n\nThat tells us that you have identical file contents in two files whose\nnames differ only in case.\n\nThis is important: Different name for git. Same name for OS. Same\ncontents.\n\nThat should also settle your remark at the end:\n\n> I find it interesting to see that both files with the equal file name\n> (like what the only relevant file system considers equal) have the same\n> hash value. Does that qualify for your description of the \"pretty bad bug\"?\n\nNo, not a bug, just the same contents.\n\n[And before you sue me for disclosing the SHA1 above: inferring the\ncontents of the file from the SHA1 is equivalent to breaking SHA1. If\nanyone could, he'd already be busy writing a paper about it (or perhaps\nworking for the NSA).]\n\n>> * You have the byte-for-byte identical file name listed twice in the\n>> index. That would be a pretty bad bug.\n>\n> The index should usually be empty here, I guess. I really do not use\n> it. No index interaction at all.\n\nPlease read up on the index before making such statements. You do use\nthe index, because it is a very important part of how git operates\nwhenever the operation also involves the worktree. And except in border\ncases (new empty repo etc.) it should never be empty.\n\nYour paste of\n\n $ git status -s\n [no output]\n\ntells us that the index has *no differences* to your worktree, nor to\nHEAD.\n\n\nSo in summary, the picture in your repository is:\n\n* Somehow you got a different-only-in-case file pair into your\n repository. It's already in HEAD. See below.\n\n* The index and worktree are healthy and unchanged (w.r.t. HEAD) from\n Git's POV. (This is possible despite the different-only-in-case files\n because they have the same contents.)\n\nFor now I'm siding with Erik's theory\n\nErik Faye-Lund wrote:\n} Very speculative comment: This might be a bug in TortoiseGit. Looking\n} at the sources, it seems they are using libgit2 to mess around with\n} the index; perhaps it's case-sensitivity code isn't as well tested as\n} Git for Windows'?\n\nIt would also be interesting to know for how long this problem has\nexisted. You can search for the offending commit with something like\n\n git log --name-status --diff-filter=A -- \"PosterWantsItCensored.*\"\n\nwhich should normally give you just one or two commits, namely the\none(s) that introduced the two files.\n\nAs for the fix, there are two-and-two-thirds cases. First I'd like to\npoint out, however, that I have no idea how core.ignoreCase interacts\nwith rm --cached. I'm assuming you have to set it to 'false' for the\nrecipes below to work. Erik or Peff may correct me. You should set it\nto 'true' again for real work.\n\nCase 1: The commit that introduced the second spelling is HEAD\n\n In this case you're sort of lucky because it's easy to fix. You can\n do\n\n git rm --cached PosterWantsItCensored.designer.cs\n\n to get rid of the spelling you do not want. Then run\n\n git status -s\n\n again to verify that it did the right thing; it should say\n\n D PosterWantsItCensored.designer.cs\n\n where it's important that a) the other spelling does *not* show up in\n the list anywhere and b) the D is in the leftmost column. Once you\n have verified this, run\n\n git commit --amend\n\n to fix HEAD.\n\nCase 2a: The commit that introduced it is older, but you don't care if\n you cannot sanely checkout old commits\n\n This is the case that I personally would never choose, since I care\n about history, but for completeness: proceed as for case 1, except at\n the end run\n\n git commit # no --amend\n\n and write a nice message saying that you fixed the\n different-only-in-case issue.\n\nCase 2b: The commit that introduced it is older, but history since its\n parent has been linear (use gitk or some such to establish\n this)\n\n First run\n\n git log --full-history --oneline -- \"PosterWantsItCensored.*\"\n\n to see which commits touched the file. Let C be the SHA1 (or a unique\n prefix) of the earliest commit that contains\n PosterWantsItCensored.designer.cs (i.e., the wrong spelling) as\n established earlier. Then run\n\n git rebase -i C^\n\n (That's right, the SHA1 of C and then a hat.)\n\n In the editor that pops up, change 'pick' to 'edit' on every line that\n shows a SHA1 you found in the preceding git-log command. Save and\n exit.\n\n Whenever rebase stops to let you edit (you can tell by the advice\n messages it gives you), run\n\n git ls-tree HEAD -- PosterWantsItCensored.designer.cs PosterWantsItCensored.Designer.cs\n\n and check whether the SHA1s are different. Judging by what you said\n they should always be the same (otherwise please come back for more\n advice). You can then again do something very similar to Case 1 to\n the commit you're editing, like\n\n git rm --cached PosterWantsItCensored.designer.cs\n git commit --amend\n\n and finally\n\n git rebase --continue\n\n to edit the next commit. Repeat until the rebase is complete.\n\nCase 2c: History wasn't linear since C; or you're just lazy and have a\n good backup\n\n The all-safeties-off, please-fix-it-for-me version goes\n\n git filter-branch --tag-name-filter cat --index-filter '\n git rm --ignore-unmatch --cached PosterWantsItCensored.designer.cs\n ' -- --all\n\n I'm dead serious about the safeties off. You have been warned.\n\nI have not tested most of this because it would simply take even more\ntime than writing an essay-length email. If something fails or got you\nconfused, paste everything you did and the full output again so we can\nestablish what happened.\n\nAll sub-items of case 2 rewrite history. You will have to force the\npush to your \"hub\" repository that you use to exchange history, and you\nmay have to reset or rebase in the other repository. Read e.g. the\n'recovering from upstream rebase' section in man git-rebase.\n\n> (What a mess it would be if I committed something different than my\n> working directory, however that works.)\n\nYou should really read up on this, e.g.\n\n http://tomayko.com/writings/the-thing-about-git\n\nAFAIK everyone who groks the feature uses it daily.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182687","messageId":"4F15B65A.8070009@unclassified.de","threadId":"29355","inReplyTo":"87ipkaogyj.fsf@thomas.inf.ethz.ch","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Yves Goergen","fromEmail":"nospam.list@unclassified.de","sentAt":"2012-01-17T17:56:42Z","receivedAt":"2012-01-17T17:56:42Z","isPatch":false,"sender":{"key":"nospam.list@unclassified.de","avatar":null},"body":"On 17.01.2012 09:45 CE(S)T, Thomas Rast wrote:\n> It would also be interesting to know for how long this problem has\n> existed. You can search for the offending commit with something like\n> \n> git log --name-status --diff-filter=A -- \"PosterWantsItCensored.*\"\n> \n> which should normally give you just one or two commits, namely the\n> one(s) that introduced the two files.\n\nI have found two commits adding that file. The second one has the file\nwith the then-already-present name modified and the new spelling added.\nI could have noticed that at commit time, but that's the very commit\nwhere I also renamed the original files and recreated them in the Forms\ndesigner. 1) This may have led me to overlook that additional add and 2)\nthis may be the source of the spelling difference because the file was\nnewly created.\n\n> As for the fix, there are two-and-two-thirds cases. (...)\n\nThat all sounds quite complicated. The \"offending\" commit is quite a\nwhile back so replacing the last commit is not a solution.\n\nThis is just my personal repository that should help me out with finding\nchanges when I find something broken that wasn't before. Deleting and\nrecreating the \"hub\" (bare) and the other working repository would be\nokay for me in this case. I have decided that it is also okay to fix the\nerror by new commits. To avoid all further issues with this, I have\nrenamed the file, committed the deletion, renamed it back and then\ncommitted the add. The revsion in between won't compile, but it's got a\nmessage with it and the compiler error would be obvious.\n\n> You should really read up on this, e.g.\n> \n> http://tomayko.com/writings/the-thing-about-git\n> \n> AFAIK everyone who groks the feature uses it daily.\n\nIt's on my to-read list. Looks like an interesting article from reading\nthe beginning of it.\n\nI have done a test, too: I have set the core.ignorecase setting to false\n(or deleted its entry) and then renamed one of the files in my working\ndirectory only in case. TortoiseGit has offered me adding the new\nspelling for a commit. After setting the core.ignorecase setting to\ntrue, it has not offered any change to commit anymore. So it looks like\nthis is just the setting that every repository for Windows use should -\nno - must have, and it was missing here.\n\nJust like that stupid autocrlf that causes more issues than it solves. I\nregularly see files with all lines changed and the diff says that both\nfiles only differ in line endings. But I have no sure observation on\nwhether that value was set or unset in those cases. I'll have to look\nafter that, too.\n\nThese two config settings are not cloned with the repository, are they?\n\nAlso, TortoiseGit already sets ignorecase = true. So maybe the Visual\nStudio provider does the init on its own and is missing that. Or I have\nat some time cloned the repository and the setting wasn't copied over.\n\n-- \nYves Goergen \"LonelyPixel\" \nVisit my web laboratory at http://beta.unclassified.de\n"},{"id":"182781","messageId":"87k44oat2w.fsf@thomas.inf.ethz.ch","threadId":"29355","inReplyTo":"4F15B65A.8070009@unclassified.de","subject":"Re: Bug? Git checkout fails with a wrong error message","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-19T10:24:07Z","receivedAt":"2012-01-19T10:24:07Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Glad that you could fix your repository.\n\nYves Goergen writes:\n\n> Just like that stupid autocrlf that causes more issues than it solves. I\n> regularly see files with all lines changed and the diff says that both\n> files only differ in line endings. But I have no sure observation on\n> whether that value was set or unset in those cases. I'll have to look\n> after that, too.\n\nJust please remember what I tried to teach you in this thread: copy and\npaste actual command invocations and outputs, and let us do the\ninterpretation. With CRLF problems, it may in addition help to pipe\nthrough a utility that shows the presence or absence of \\r, such as 'cat\n-v'.\n\n> These two config settings are not cloned with the repository, are they?\n\nNeither config nor hooks are cloned.\n\n> Also, TortoiseGit already sets ignorecase = true. So maybe the Visual\n> Studio provider does the init on its own and is missing that. Or I have\n> at some time cloned the repository and the setting wasn't copied over.\n\ngit-clone also autodetects the setting as part of initializing the\nclone. (Copying over the repository from a case-sensitive medium using\na case-sensitive OS would of course leave it unset.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}