{"thread":{"id":"30898","subject":"fast-import [mis?]-honors core.ignorecase","startedAt":"2012-06-25T20:48:36Z","lastAt":"2012-06-26T03:45:52Z","messageCount":2,"participants":["Jay Soffian","Joshua Jensen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194228","messageId":"CAG+J_DygPXtjD-0gv8XXpV0JErw_jpwRLOZ00H9bem5hN8g7ZA@mail.gmail.com","threadId":"30898","inReplyTo":null,"subject":"fast-import [mis?]-honors core.ignorecase","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2012-06-25T20:48:36Z","receivedAt":"2012-06-25T20:48:36Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"I was using a \"fast-export | <filter program> | fast-import\" as a much\nfaster filter-branch --env-filter (I needed to rewrite\nauthor/committer email-addresses) and was surprised that after the\npipeline was done, the new ref's trees didn't match the old ref's\ntrees. i.e.:\n\n  $ cmp <(git log old-ref --pretty='%T')  <(git log --pretty='%T' new-ref)\n\ndidn't return 0. Comparing one of the differing tree-pairs indicated\nit was due to a case-difference in a file which had been renamed.\nAfter some experimenting I finally tracked this down to having\ncore.ignorecase set to \"true\" on the repo in which I was running the\npipeline. By setting it to \"false\" the filtering pipeline completes\nwith new-ref (and all its ancestors) being tree-identical to old-ref.\n\nIs there any reason for fast-import to honor ignorecase?\n\nj.\n"},{"id":"194256","messageId":"4FE93070.1050507@workspacewhiz.com","threadId":"30898","inReplyTo":"CAG+J_DygPXtjD-0gv8XXpV0JErw_jpwRLOZ00H9bem5hN8g7ZA@mail.gmail.com","subject":"Re: fast-import [mis?]-honors core.ignorecase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2012-06-26T03:45:52Z","receivedAt":"2012-06-26T03:45:52Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Jay Soffian\nDate: 6/25/2012 2:48 PM\n> I was using a \"fast-export | <filter program> | fast-import\" as a much\n> faster filter-branch --env-filter (I needed to rewrite\n> author/committer email-addresses) and was surprised that after the\n> pipeline was done, the new ref's trees didn't match the old ref's\n> trees. i.e.:\n>\n>    $ cmp <(git log old-ref --pretty='%T')  <(git log --pretty='%T' new-ref)\n>\n> didn't return 0. Comparing one of the differing tree-pairs indicated\n> it was due to a case-difference in a file which had been renamed.\n> After some experimenting I finally tracked this down to having\n> core.ignorecase set to \"true\" on the repo in which I was running the\n> pipeline. By setting it to \"false\" the filtering pipeline completes\n> with new-ref (and all its ancestors) being tree-identical to old-ref.\n>\n> Is there any reason for fast-import to honor ignorecase?\nI provided this change in ac1c80f7645b6fa90534890e1f83005d40d98281.\n\nIn my mind, core.ignorecase=true means that the file system cannot \nhandle case-sensitive filenames.  Files held in the repository should \nconform to a single case.\n\nWhen I was getting a 'fast export' of our Perforce repository, I found \nfile case was all over the map.  Perforce internally handles its files \nfor a case preserving case insensitive file system in a case insensitive \nmanner.  File case can change from changelist to changelist!  The \nfast-exported file was a mess.  In the original fast-imported version, \n'git status' thought that one case of file was modified when another \ncase of the same file was the same.  Git could not follow the history \nover all of the filename case changes.\n\nThe case folding patches were created to handle this.  Specifically, the \nfast-import patch serves as a catch-all to handle repositories that do \nnot conform to a single case as they were created and in operation.  It \nfolds the incoming file case to match that of what is in the existing \nrepository.  The end result is a clean repository with one file case for \na given filename.  'git status' works.  File history can be followed.  \n'git add' knows which name to match against.\n\n(I am a firm believer that Git should handle *all* case _internally_ as \ninsensitive when core.ignorecase=true, and I have work-in-progress \npatches that illustrate this behavior.  Others here (particularly on the \nmsysgit mailing list) are adamantly against those patches.  Nonetheless, \nthere would be no need to fold case if the Git internals handled \ncomparisons in a case insensitive fashion.)\n\nI do understand your point above, and I have no good answer.  Your file \ncase was changed during a rename.  The fast-import core.ignorecase=true \nprocess did not preserve that case change despite it being right and \nappropriate for your repository. core.ignorecase=false did preserve the \ncase.  I guess the solution here depends on what core.ignorecase=true \nshould mean.\n\nNevertheless, I am certain Git fast-import needs to retain the case \nfolding behavior during fast-import, even if it means enabling it via a \ncommand-line flag instead of core.ignorecase=true.\n\n-Josh\n"}]}