{"thread":{"id":"44069","subject":"Potential Same Name Bug","startedAt":"2016-09-12T23:30:18Z","lastAt":"2016-09-13T00:35:55Z","messageCount":2,"participants":["Kevin Smith","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"301781","messageId":"CAOY7EmCYjajQPPAVhAhzt7g0yA=QH2R9HZEAhztUo2JbfSiCwQ@mail.gmail.com","threadId":"44069","inReplyTo":null,"subject":"Potential Same Name Bug","fromName":"Kevin Smith","fromEmail":"noiz77@gmail.com","sentAt":"2016-09-12T23:29:51Z","receivedAt":"2016-09-12T23:30:18Z","isPatch":false,"sender":{"key":"noiz77@gmail.com","avatar":null},"body":"I hit an issue in Git today that seemed to be a bug.  Basically what\nhappened is in our master branch we had two files, one named something\nlike \"file_NAME.png\" and another named \"file_name.png\" in the same\nfolder.  In the develop branch in the same repo we had removed the\n\"file_NAME.png\" file so that only the \"file_name.png\" file was left.\nIf I clone the repo so I get master and then do \"git checkout develop\"\nI would see when running \"git status\" that I would have this message:\n\nOn branch develop\nYour branch is up-to-date with 'origin/develop'.\nChanges not staged for commit:\n  (use \"git add/rm <file>...\" to update what will be committed)\n  (use \"git checkout -- <file>...\" to discard changes in working directory)\n\n        deleted:    file_name.png\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nSo when I move from master to develop that status would come up.  If I\nran \"git reset --hard\" I would no longer have that message.  I also\nsaw that when I do a git clone and specify to clone the develop branch\nthat I would not see the git status above.  Is this an issue where if\none branch has two files of the same name where one gets removed that\nit will remove both instances of that file in another branch when you\nswitch to it?  I fixed this issue in our repo by removing the\n\"file_NAME.png\" file in the master branch, but it seems like this\nshould be handled better in the case I described.\n"},{"id":"301797","messageId":"CAH5451nEq77uiSaY7mYCKXx4Ybp1nY8FHcAPwUkFQkf6a4xJpg@mail.gmail.com","threadId":"44069","inReplyTo":"CAOY7EmCYjajQPPAVhAhzt7g0yA=QH2R9HZEAhztUo2JbfSiCwQ@mail.gmail.com","subject":"Re: Potential Same Name Bug","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2016-09-13T00:35:08Z","receivedAt":"2016-09-13T00:35:55Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Hi Kevin,\n\nOn 13 September 2016 at 09:29, Kevin Smith <noiz77@gmail.com> wrote:\n> So when I move from master to develop that status would come up.  If I\n> ran \"git reset --hard\" I would no longer have that message.  I also\n> saw that when I do a git clone and specify to clone the develop branch\n> that I would not see the git status above.  Is this an issue where if\n> one branch has two files of the same name where one gets removed that\n> it will remove both instances of that file in another branch when you\n> switch to it?  I fixed this issue in our repo by removing the\n> \"file_NAME.png\" file in the master branch, but it seems like this\n> should be handled better in the case I described.\n\nJust to clarify, is the machine you are cloning to on a\ncase-insensitive file system, or have you set core.ignorecase=true?\n\nIf so, I would imagine the behaviour would have been _interesting_ in\nthat repository before you removed one of the versions - that may be\nwhy you removed it in the first place.\n\nFor future reference, the typical way I have seen this situation dealt\nwith is to git mv one file to a different filename, or using git rm.\nThere may be better ways to do it, and it's possible git should deal\nwith the specific situation you mentioned better, but I'm not able to\ncomment on that.\n\nThis situation commonly arises when you set core.ignorecase=false on a\ncase insensitive file system and then rename a file. When you commit\nthat change, git doesn't notice that the old filename has been\n'deleted' (git sees a rename as a delete+create with the same file\ncontents) and so now thinks that you have two files with very similar\nnames in your working directory. To avoid this, make sure\ncore.ignorecase is set correctly, and use git mv -f to rename files on\ncase insensitive file systems.\n\nDetails at https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git\n\nRegards,\n\nAndrew Ardill\n"}]}