Re: Is git-checkout's restoring d/f conflict really sane?

[Junio C Hamano <gitster@pobox.com>]

Duy Nguyen <pclouds@gmail.com> writes:

> $ echo data > one
> $ git add one
> $ rm one
> $ mkdir one
> $ echo two > one/two
> $ echo three > one/three
> $ git checkout one
> $ ls -l one
> -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
>
> Replacing a file is one thing. In this case we're deleting a directory
> and unknown number of files inside (in this case 'two' and 'three').
> Is this really a good thing to do?
>
> If it's not but too late to do anything about git-checkout, could
> git-restore do something better (and exactly what)?

The user said "I do not want whatever I have under name 'one' in the
working tree, and I want what I have as 'one' in the index instead",
so I tend to think that failing the request would be a disservice.

I suspect that this will become even more right thing to do, in the
new world where the no-overlay mode becomes the default.  Unlike
"checkout HEAD ."  that only adds to the set of paths in the working
tree, "restore HEAD ." will remove what's in the working tree and in
the index but not in the HEAD, no?