Re: [PATCH v1 10/11] completion: support restore
- Date: Mon, 11 Mar 2019 22:39:57 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [PATCH v1 10/11] completion: support restore
On Mon, Mar 11, 2019 at 10:22 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren <newren@xxxxxxxxx> wrote:
> > On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
> > >
> > > Completion for restore is straightforward. We could still do better
> > > though by give the list of just tracked files instead of all present
> > > ones. But let's leave it for later.
> > s/give/giving/
> > I'm slightly worried that due to using --no-overlay mode by default in
> > restore, having tab-completion include untracked files increases the
> > risk of accidentally nuking the wrong file. restore is a destructive
> > command anyway and should thus be used with care, so perhaps this
> > isn't a big deal, but I thought I'd mention it.
> This makes me think about my "git restore :/" example, which does not
> remove untracked files because its source is the index. But isn't it
> inconsistent that we only remove untracked files with --source and
> keep them without? Will that just confuse people more? Or did I just
> forget to implement no-overlay mode for the index too?
Nope you confused me. non-overlay mode never touches untracked files
and so neither does git-restore.
It does make the description of git-restore about "remove if paths do
not exist" incorrect. But frankly I find it hard to explain
non-overlay mode with the index being the remove filter. In
git-checkout, where we update both index and worktree, this may make
sense to use the index as the remove filter. But worktree works on the
worktree only by default. I'll need to sleep on this.