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

From: Ben Peart <peartben@gmail.com>
Date: Jan 16, 2019, 14:39 UTC
Message-ID: <e9284bc1-0db2-6f90-6e8e-3a7682c03dd0@gmail.com>
In-Reply-To: <CA+dzEB=oeL2oByqiH4FeCHc29yGL2TwhmO1DKmRTDx8Xdhh=NQ@mail.gmail.com>

On 1/3/2019 5:05 PM, Anthony Sottile wrote:

Show 36 quoted lines

> On Thu, Jan 3, 2019 at 1:51 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Anthony Sottile <asottile@umich.edu> writes:
>>
>>> 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 ;-).
>>
>>

Just noticed this thread. I agree that the behavior of `git clone --no-checkout` is a little odd in that it shows everything as deleted but the goal of the `checkout -b` optimization was to not change behavior (unless the user opt-ed in to the changed behavior via checkout.optimizeNewBranch). I'll work on a patch to detect this case and ensure the default behavior doesn't change.

Show 9 quoted lines

> 
> oh wow, I didn't realize `git checkout -b newbranch` also used to
> reset the `--no-checkout` state, yeah you're right the optimization is
> way more problematic than I had considered.
> 
> I'm working around by not using `--no-checkout` personally
> 
> Anthony
>