Re: Regression `git checkout $rev -b branch` while in a `--no-checkout` clone does not check out files
- Date: Thu, 03 Jan 2019 12:25:57 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: Regression `git checkout $rev -b branch` while in a `--no-checkout` clone does not check out files
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
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".