{"thread":{"id":"31007","subject":"Question: git clone --no-checkout behavior","startedAt":"2012-07-12T12:51:31Z","lastAt":"2012-07-12T22:02:02Z","messageCount":3,"participants":["Bryan Turner","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194964","messageId":"CAGyf7-EZOSiATo3yF5x+FT6_QAkMTJ+AmrE27kwmxLkLXdaJKg@mail.gmail.com","threadId":"31007","inReplyTo":null,"subject":"Question: git clone --no-checkout behavior","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2012-07-12T12:51:31Z","receivedAt":"2012-07-12T12:51:31Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"I've witnessed the following behavior in both git 1.7.6 and 1.7.10.4.\n\nAssume I have a bare clone, some-repo.git. If I run:\n- git clone --shared --no-checkout /path/to/some-repo.git shared-repo\n- cd shared-repo\n- git status\n\nI see that every file in the repository is _staged_ for deletion. I'm\nnot surprised every file shows deleted; I'm surprised that the\ndeletion starts out already staged. A git reset unstages all of the\ndeletions and I'm good to go. I'm just wondering why they're all\nstaged in the first place; it seems counter-intuitive.\n\nCan anyone shed some light on this?\nBryan Turner\n"},{"id":"194973","messageId":"7vliioc1yn.fsf@alter.siamese.dyndns.org","threadId":"31007","inReplyTo":"CAGyf7-EZOSiATo3yF5x+FT6_QAkMTJ+AmrE27kwmxLkLXdaJKg@mail.gmail.com","subject":"Re: Question: git clone --no-checkout behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-12T17:40:32Z","receivedAt":"2012-07-12T17:40:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Turner <bturner@atlassian.com> writes:\n\n> I've witnessed the following behavior in both git 1.7.6 and 1.7.10.4.\n>\n> Assume I have a bare clone, some-repo.git. If I run:\n> - git clone --shared --no-checkout /path/to/some-repo.git shared-repo\n> - cd shared-repo\n> - git status\n\nI do not recall we *designed* it in such a way that you would commit\nan empty tree if you run \"git commit\" immediately after making such\na clone.  But I do not think it is a bug, either.\n\nI think the most likely reason nobody even noticed this is because\nthe expected use scenario for --no-checkout is when user does not\nknow (and does not care to find out) what branch is checked out (if\nnonbare) or marked as the primary (if bare) in the repository she is\ncloning from, and will checkout the branch she wants to work on\nimmediately after cloning, i.e.\n\n\tgit clone -n $over_there here\n        cd here\n\t# she knows she wants to fork from 'nitfol'\n        git checkout -t -b frotz origin/nitfol\n\nNot having anything in the $GIT_DIR/index (which is why you see\n\"everything is removed from the index, you will commit an empty\ntree\" in the status output) does not matter in this scenario,\nbecause the first command she invokes will be \"git checkout\".\n\nIf you populated $GIT_DIR/index from the tree of HEAD, you would see\neverything is deleted in the working tree.  You can simulate it by\ndoing this:\n\n\tgit clone -n $over_there here\n        cd here\n\tgit read-tree HEAD\n\tgit status\n\nBut it would not help people who want to check another branch out\nimmediately after cloning with -n, which is the whole point of the\noption, so...\n"},{"id":"194989","messageId":"7vbojkabad.fsf@alter.siamese.dyndns.org","threadId":"31007","inReplyTo":"CAGyf7-Fkn9bjJ9EZEFNsba8U-RUzrB3TzmB-YbcvwUFRbHXG+Q@mail.gmail.com","subject":"Re: Question: git clone --no-checkout behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-12T22:02:02Z","receivedAt":"2012-07-12T22:02:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bryan Turner <bturner@atlassian.com> writes:\n\n>> If you populated $GIT_DIR/index from the tree of HEAD, you would see\n>> everything is deleted in the working tree.  You can simulate it by\n>> doing this:\n>>\n>>         git clone -n $over_there here\n>>         cd here\n>>         git read-tree HEAD\n>>         git status\n>>\n>> But it would not help people who want to check another branch out\n>> immediately after cloning with -n, which is the whole point of the\n>> option, so...\n>\n> Is the reset call in my example in essence performing that same read-tree,\n> when it unstages the changes?\n\n\"git reset\" (without any other parameters) reads the HEAD tree into\nthe index without touching the working tree, so I think it is\nprobably equivalent.\n"}]}