{"thread":{"id":"24881","subject":"Does changing filename case breaks git's rename heuristic?","startedAt":"2010-08-27T04:57:43Z","lastAt":"2010-08-28T10:39:40Z","messageCount":8,"participants":["Dan Loewenherz","Ramkumar Ramachandra","Michael J Gruber","Stephen Bash","Jay Soffian","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149106","messageId":"AANLkTinxvj85Jzb-ykK0=MmRHkz8aQzmVxexC8H+Xgno@mail.gmail.com","threadId":"24881","inReplyTo":null,"subject":"Does changing filename case breaks git's rename heuristic?","fromName":"Dan Loewenherz","fromEmail":"dloewenherz@gmail.com","sentAt":"2010-08-27T04:57:43Z","receivedAt":"2010-08-27T04:57:43Z","isPatch":false,"sender":{"key":"dloewenherz@gmail.com","avatar":"https://gravatar.com/avatar/69134b10dc6663fd8a4ac95edc0e556662c43c3acb226cec9f697cb8848198b2?d=mp&s=160"},"body":"Hi all,\n\nI may be mistaking a design decision as a bug, but I wanted to throw\nthis out to the list to make sure. I think that re-enacting it will be\nthe best way to explain it.\n\n$ mkdir test\n$ cd test\n$ git init\n$ cat > readme\nThis is a test file.\n^D\n$ git commit -am \"first commit\"\n[master (root-commit) fae0d05] first commit\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nFor personal reasons, I now want readme to be uppercase.\n\n$ mv readme README\n$ cat > README\nThis is the revised README.\n$ git status -sb\n## master\n M readme\n$ git add README\n$ git status -sb\n## master\n M readme\n\nAt this point, I'm thinking that git is confused. Even though I've\nadded the README file, it still isn't staged. I follow up with the\nobvious:\n\n$ git add readme\n$ git status -sb\n## master\nM  readme\n$ git commit -m \"change filename\"\n[master ecc009f] change filename\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\nIt kind of works, but not quite, since git still thinks the file is\ncalled readme. I'd like to rename it, but whenever I run:\n\n$ git mv readme README\nfatal: destination exists, source=readme, destination=README\n\nHow about this:\n\n$ mv README README.temp\n$ git mv readme README\nfatal: bad source, source=readme, destination=README\n\nThe only workable solution was this:\n\n$ git mv readme readme.temp\n$ git mv readme.temp README\n\nI'm guessing this all has to do in some part with the logic behind\ngit's strategy for detecting renames. This case probably slipped under\nthe radar.\n\n-Dan\n"},{"id":"149108","messageId":"20100827053629.GC22527@kytes","threadId":"24881","inReplyTo":"AANLkTinxvj85Jzb-ykK0=MmRHkz8aQzmVxexC8H+Xgno@mail.gmail.com","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-08-27T05:36:32Z","receivedAt":"2010-08-27T05:36:32Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Dan,\n\nDan Loewenherz writes:\n> I may be mistaking a design decision as a bug, but I wanted to throw\n> this out to the list to make sure. I think that re-enacting it will be\n> the best way to explain it.\n> \n> $ mkdir test\n> $ cd test\n> $ git init\n> $ cat > readme\n> This is a test file.\n> ^D\n> $ git commit -am \"first commit\"\n> [master (root-commit) fae0d05] first commit\n>  1 files changed, 1 insertions(+), 0 deletions(-)\n> \n> For personal reasons, I now want readme to be uppercase.\n> \n> $ mv readme README\n> $ cat > README\n> This is the revised README.\n> $ git status -sb\n> ## master\n>  M readme\n[...]\n\nThanks for taking the time to explain! Unfortunately, I'm not able to\nreproduce this. Which version of Git are you using, and which platform\nare you on?\n\n-- Ram\n"},{"id":"149112","messageId":"4C777090.2000107@drmicha.warpmail.net","threadId":"24881","inReplyTo":"AANLkTinxvj85Jzb-ykK0=MmRHkz8aQzmVxexC8H+Xgno@mail.gmail.com","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-08-27T08:00:16Z","receivedAt":"2010-08-27T08:00:16Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:\n> Hi all,\n> \n> I may be mistaking a design decision as a bug, but I wanted to throw\n> this out to the list to make sure. I think that re-enacting it will be\n> the best way to explain it.\n> \n> $ mkdir test\n> $ cd test\n> $ git init\n> $ cat > readme\n> This is a test file.\n> ^D\n> $ git commit -am \"first commit\"\n> [master (root-commit) fae0d05] first commit\n>  1 files changed, 1 insertions(+), 0 deletions(-)\n\n? You have not added any file, so git won't commit anything (not even\nwith -a). The above can't be a complete transcription. I assume you've\nadded readme with the content above.\n\n> \n> For personal reasons, I now want readme to be uppercase.\n> \n> $ mv readme README\n\nHere's where using \"git mv\" would have been the easier choice, followed\nby commit.\n\n> $ cat > README\n> This is the revised README.\n\nRenaming and changing the content completely in one step will always\ntrip up git's rename detection. You should rename, commit, change,\ncommit, unless the change affects a small portion of the file only.\n\n> $ git status -sb\n> ## master\n>  M readme\n\nAgain, this can't be a complete transcript. The above would lead to\n\n D readme\n?? README\n\n> $ git add README\n> $ git status -sb\n> ## master\n>  M readme\n> \n> At this point, I'm thinking that git is confused. Even though I've\n\nAre you possibly using a case-challenged file system? Is this maybe on a\nMac with HFS or Win with NTFS?\n\nMichael\n"},{"id":"149123","messageId":"AANLkTikN_PbNNH2f4zWuk1FH+LgpKzkoZ6mYOdT9ANBj@mail.gmail.com","threadId":"24881","inReplyTo":"4C777090.2000107@drmicha.warpmail.net","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Dan Loewenherz","fromEmail":"dloewenherz@gmail.com","sentAt":"2010-08-27T14:52:11Z","receivedAt":"2010-08-27T14:52:11Z","isPatch":false,"sender":{"key":"dloewenherz@gmail.com","avatar":"https://gravatar.com/avatar/69134b10dc6663fd8a4ac95edc0e556662c43c3acb226cec9f697cb8848198b2?d=mp&s=160"},"body":"On Fri, Aug 27, 2010 at 1:00 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:\n>> Hi all,\n>>\n>> I may be mistaking a design decision as a bug, but I wanted to throw\n>> this out to the list to make sure. I think that re-enacting it will be\n>> the best way to explain it.\n>>\n>> $ mkdir test\n>> $ cd test\n>> $ git init\n>> $ cat > readme\n>> This is a test file.\n>> ^D\n>> $ git commit -am \"first commit\"\n>> [master (root-commit) fae0d05] first commit\n>>  1 files changed, 1 insertions(+), 0 deletions(-)\n>\n> ? You have not added any file, so git won't commit anything (not even\n> with -a). The above can't be a complete transcription. I assume you've\n> added readme with the content above.\n\nYep, that was my mistake. I left out 'git add readme'.\n\n>\n>>\n>> For personal reasons, I now want readme to be uppercase.\n>>\n>> $ mv readme README\n>\n> Here's where using \"git mv\" would have been the easier choice, followed\n> by commit.\n\nI agree. The instance where this actually occurred was that I had\nreceived an updated binary file to put into my repository. icon.png ->\nIcon.png. I suppose I could've run 'git mv' but I didn't realize what\nwould happen if I didn't!\n\n>\n>> $ cat > README\n>> This is the revised README.\n>\n> Renaming and changing the content completely in one step will always\n> trip up git's rename detection. You should rename, commit, change,\n> commit, unless the change affects a small portion of the file only.\n\nAgreed.\n\n>\n>> $ git status -sb\n>> ## master\n>>  M readme\n>\n> Again, this can't be a complete transcript. The above would lead to\n>\n>  D readme\n> ?? README\n\nThis is where I didn't botch up the transcript, and where I was\nactually surprised at what was going on. I'll insert a full one at the\nbottom of this email that can actually be run to get the same results.\n\n>\n>> $ git add README\n>> $ git status -sb\n>> ## master\n>>  M readme\n>>\n>> At this point, I'm thinking that git is confused. Even though I've\n>\n> Are you possibly using a case-challenged file system? Is this maybe on a\n> Mac with HFS or Win with NTFS?\n\nI'm using a Mac with a journaled filesystem and Git version 1.7.2.1.\n\n>\n> Michael\n>\n\nTranscript\n\ndan ~ $ mkdir test\ndan ~ $ cd test/\ndan test $ git init\nInitialized empty Git repository in /Users/dan/test/.git/\ndan test (master #) $ cat > readme\nThis is a test file.\ndan test (master #%) $ git add readme\ndan test (master #) $ git ci -m \"first commit\"\n[master (root-commit) 3237fcb] first commit\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 readme\ndan test (master) $ mv readme README\ndan test (master) $ cat > README\nThis is the revised README.\ndan test (master *) $ git s\n## master\n M readme\ndan test (master *) $ git add README\ndan test (master *) $ git s\n## master\n M readme\ndan test (master *) $ git add readme\ndan test (master +) $ git s\n## master\nM  readme\ndan test (master +) $ git ci -m \"change filename\"\n[master 587f3f8] change filename\n 1 files changed, 1 insertions(+), 1 deletions(-)\ndan test (master) $ git --version\ngit version 1.7.2.1\n"},{"id":"149125","messageId":"4C77DDDC.8070407@drmicha.warpmail.net","threadId":"24881","inReplyTo":"AANLkTikN_PbNNH2f4zWuk1FH+LgpKzkoZ6mYOdT9ANBj@mail.gmail.com","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-08-27T15:46:36Z","receivedAt":"2010-08-27T15:46:36Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Dan Loewenherz venit, vidit, dixit 27.08.2010 16:52:\n> On Fri, Aug 27, 2010 at 1:00 AM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Dan Loewenherz venit, vidit, dixit 27.08.2010 06:57:\n>>> Hi all,\n>>>\n>>> I may be mistaking a design decision as a bug, but I wanted to throw\n>>> this out to the list to make sure. I think that re-enacting it will be\n>>> the best way to explain it.\n>>>\n>>> $ mkdir test\n>>> $ cd test\n>>> $ git init\n>>> $ cat > readme\n>>> This is a test file.\n>>> ^D\n>>> $ git commit -am \"first commit\"\n>>> [master (root-commit) fae0d05] first commit\n>>>  1 files changed, 1 insertions(+), 0 deletions(-)\n>>\n>> ? You have not added any file, so git won't commit anything (not even\n>> with -a). The above can't be a complete transcription. I assume you've\n>> added readme with the content above.\n> \n> Yep, that was my mistake. I left out 'git add readme'.\n> \n>>\n>>>\n>>> For personal reasons, I now want readme to be uppercase.\n>>>\n>>> $ mv readme README\n>>\n>> Here's where using \"git mv\" would have been the easier choice, followed\n>> by commit.\n> \n> I agree. The instance where this actually occurred was that I had\n> received an updated binary file to put into my repository. icon.png ->\n> Icon.png. I suppose I could've run 'git mv' but I didn't realize what\n> would happen if I didn't!\n> \n>>\n>>> $ cat > README\n>>> This is the revised README.\n>>\n>> Renaming and changing the content completely in one step will always\n>> trip up git's rename detection. You should rename, commit, change,\n>> commit, unless the change affects a small portion of the file only.\n> \n> Agreed.\n> \n>>\n>>> $ git status -sb\n>>> ## master\n>>>  M readme\n>>\n>> Again, this can't be a complete transcript. The above would lead to\n>>\n>>  D readme\n>> ?? README\n> \n> This is where I didn't botch up the transcript, and where I was\n> actually surprised at what was going on. I'll insert a full one at the\n> bottom of this email that can actually be run to get the same results.\n> \n>>\n>>> $ git add README\n>>> $ git status -sb\n>>> ## master\n>>>  M readme\n>>>\n>>> At this point, I'm thinking that git is confused. Even though I've\n>>\n>> Are you possibly using a case-challenged file system? Is this maybe on a\n>> Mac with HFS or Win with NTFS?\n> \n> I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.\n\nThe journalling is no problem, but HFS is. I'm no Macxpert but if I\nremember correctly, then under HFS \"readme\" and \"README\" are the same\nfile, i.e. HFS only remembers how you want it spelled. People will\ncorrect me where I'm wrong.\n\nYour test script should produce the expected result if you use, say,\n\"readme\" and \"RAEDME\" , i.e. names which differ by more than just case.\n\nCheers,\nMichael\n\n> Transcript\n[snipped]\n"},{"id":"149127","messageId":"29718856.121438.1282926174106.JavaMail.root@mail.hq.genarts.com","threadId":"24881","inReplyTo":"4C77DDDC.8070407@drmicha.warpmail.net","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2010-08-27T16:22:54Z","receivedAt":"2010-08-27T16:22:54Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"\n> > I'm using a Mac with a journaled filesystem and Git version 1.7.2.1.\n> \n> The journalling is no problem, but HFS is. I'm no Macxpert but if I\n> remember correctly, then under HFS \"readme\" and \"README\" are the same\n> file, i.e. HFS only remembers how you want it spelled. People will\n> correct me where I'm wrong.\n> \n> Your test script should produce the expected result if you use, say,\n> \"readme\" and \"RAEDME\" , i.e. names which differ by more than just\n> case.\n\nIt's a problem on some (most?) Macs.  A while back Apple introduced an option to format a partition as case sensitive (Wikipedia implies 10.3 introduced this feature).  For a long time after the feature was introduced the factory install continued to be not case sensitive, but I don't know if that's still the case (no pun intended).\n\nStephen\n"},{"id":"149138","messageId":"AANLkTikPcPAGn6VMiD9Mbxfq3rdU4EeHsd32qniYu5VZ@mail.gmail.com","threadId":"24881","inReplyTo":"4C77DDDC.8070407@drmicha.warpmail.net","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-08-27T20:02:18Z","receivedAt":"2010-08-27T20:02:18Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Aug 27, 2010 at 11:46 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> The journalling is no problem, but HFS is. I'm no Macxpert but if I\n> remember correctly, then under HFS \"readme\" and \"README\" are the same\n> file, i.e. HFS only remembers how you want it spelled. People will\n> correct me where I'm wrong.\n\nThat's correct, HFS is case-preserving but case-insensitve. There is a\ncase-sensitive variant but it is not the default and sadly, some\napplications assume case-insensitity and will break if the system\nvolume is otherwise.\n\nj.\n"},{"id":"149161","messageId":"AANLkTi=89_QvzNf44OLL6K9-5uG6WLrMtHsA9cbmrCt1@mail.gmail.com","threadId":"24881","inReplyTo":"4C77DDDC.8070407@drmicha.warpmail.net","subject":"Re: Does changing filename case breaks git's rename heuristic?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-28T10:39:40Z","receivedAt":"2010-08-28T10:39:40Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Aug 27, 2010 at 15:46, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n\n> The journalling is no problem, but HFS is. I'm no Macxpert but if I\n> remember correctly, then under HFS \"readme\" and \"README\" are the same\n> file, i.e. HFS only remembers how you want it spelled. People will\n> correct me where I'm wrong.\n\nFWIW this is called \"case preserving\". Where the filesystem is\ncase-insensitive so that you can't create both \"foo\" and \"FOO\", but it\nstill remembers if you did \"touch Foo\", \"touch FoO\" or whatever.\n\nIt affects more filesystems than just HFS.\n"}]}