From: Ben Peart Date: Wed, 16 Jan 2019 14:39:16 GMT Subject: Re: Regression `git checkout $rev -b branch` while in a `--no-checkout` clone does not check out files Message-ID: In-Reply-To: On 1/3/2019 5:05 PM, Anthony Sottile wrote: > On Thu, Jan 3, 2019 at 1:51 PM Junio C Hamano wrote: >> >> Anthony Sottile writes: >> >>> On Thu, Jan 3, 2019 at 12:26 PM Junio C Hamano 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. > > 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 >