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