Re: Regression `git checkout $rev -b branch` while in a `--no-checkout` clone does not check out files

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2019, 21:51 UTC
Message-ID: <xmqqwonlfm0g.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CA+dzEB=+ROLVjp36SQjucouc8YUWTvYBrN4QyS5fsStMPtbw_w@mail.gmail.com>

Anthony Sottile <asottile@umich.edu> writes:

Show 18 quoted lines

> On Thu, Jan 3, 2019 at 12:26 PM Junio C Hamano <gitster@pobox.com> wrote:
>> 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().
>
> I think it might be simpler than that even -- the optimization treats
> the following as equivalent when the current checked out revision is
> deadbeef (even if the index / worktree differ), when before they were
> not:
>
> - git checkout -b newbranch
> - git checkout deadbeef -b newbranch
>
> If a revision is specified on the commandline it should be checked out.

If it were to be a "fix", the exact same command line as people used to be able to use, i.e. "git checkout -b newbranch", should be made to do what it used to do.

Forcing users to use a different command to workaround the bug is not a usable "fix". If we want a working workaround, you can tell your users to use

    git reset --hard HEAD && git checkout -b newbranch

and that would already work without any code change ;-).