Duy Nguyen <pclouds@xxxxxxxxx> writes: > I plan to revert this commit anyway when the new command "git > switch-branch" comes. The optimization will be unconditionally in the > new command without this hack and users are encouraged to use that one > instead of "git checkout". I tend to think that the behaviour is perfectly in line with what Ben wanted to have, which is to make "checkout -b new [HEAD]" not to touch anything in the index or the working tree at all. It further is possible to argue that what is strange in the whole episode is what "clone --no-checkout" does. In such a repository, if you say "git status", you'd notice that it is reported that all paths have been deleted. Now, if you instead do git clone $src dst cd dst git rm file git checkout -b new i.e. starting from a clone with normal working tree, manually removing a path or two, and then create a new branch starting from that state while carrying all the local changes, you *do* want to see that 'file' to stay missing. After all, "do not lose the local changes; carry them forward" is what switching branches is about. And from that point of view, we could consider that git clone --no-checkout $src $dst is equivalent to git clone $src $dst && git -C $dst rm -r . Having said all that. > Meanwhile, let's see if Ben wants to fix this or revert it. A "fix" to Ben's optimization for this particular case should be fairly straight-forward. I think we have a special case in the checkout codepath for an initial checkout and disable "carry forward the fact that the user wanted all the paths removed", so it would be the matter of adding yet another condition (is_cache_unborn(), which is used to set topts.initial_checkout) to the large collection of conditions in skip_merge_working_tree(). Back when the "optimization" was discussed, all reviewers said that it would become maintenance nightmare to ensure that the set of conditions accurately tracks the case where the optimization is safe. Now they are entitled to say "we told you so".
