{"thread":{"id":"44300","subject":"Why does git checkout -b touch the index?","startedAt":"2016-10-14T14:36:36Z","lastAt":"2016-10-14T16:08:42Z","messageCount":2,"participants":["David Turner","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"304163","messageId":"1476455756.32360.2.camel@frank","threadId":"44300","inReplyTo":null,"subject":"Why does git checkout -b touch the index?","fromName":"David Turner","fromEmail":"novalis@novalis.org","sentAt":"2016-10-14T14:35:56Z","receivedAt":"2016-10-14T14:36:36Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"If I do \"git checkout -b fleem\", with no additional flags, why does it\nneed to rewrite the index?  Or even read the index? \n\n(this is kind of a bug report, I guess, but it's a pretty minor bug that\nI only noticed because I was out of hard drive space)\n\n"},{"id":"304169","messageId":"xmqq4m4e29t0.fsf@gitster.mtv.corp.google.com","threadId":"44300","inReplyTo":"1476455756.32360.2.camel@frank","subject":"Re: Why does git checkout -b touch the index?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-14T16:07:55Z","receivedAt":"2016-10-14T16:08:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Turner <novalis@novalis.org> writes:\n\n> If I do \"git checkout -b fleem\", with no additional flags, why does it\n> need to rewrite the index?  Or even read the index? \n\nThe \"reading\" part can be explained easily.\n\nIt needs to show the list of dirty paths, which involves reading the\nindex, refreshing them in-core to cull the timestamp-only changes\nout of the report.  \n\nOnce in-core index is refreshed, it is a waste not to write them out\nif it can, so it is not surprising if it writes, too.\n\nThe real reason is a lot more involved.  \"git checkout -b new\" is\ndifferent from \"git update-ref refs/heads/new HEAD\" (i.e. create a\nnew branch at the same commit) followed by \"git symbolic-ref HEAD\nrefs/heads/new\" (i.e. point the HEAD at it).  If it were, I fully\nagree with you that it shouldn't need to touch either index or\nworking tree at all.\n\nIt is \"git branch new\" followed by \"git checkout new\", and the\nlatter step does the full two-tree \"read-tree\" between the same two\ncommits.  I personally very much prefer \"Switching between the same\ntwo commits?  That should be a no-op by definition.\", but we cannot\nblindly that naive optimization, as it would break some use cases\n(which I personally do not care too much about ;-).\n\nFor example, extra working tree files outside the \"sparse\" area are\nremoved when sparse-checkout is in use while switching from the\ncurrent branch to the new and identical branch.  I do not personally\nagree with the behaviour, but that has been what the users accept;\nthere may be other funnies like that.\n"}]}