On Sun, Jun 14, 2020 at 03:44:39AM -0400, Denton Liu wrote: > Hi Eric, > > On Sat, Jun 13, 2020 at 10:51:47PM -0400, Eric Sunshine wrote: > > On Sat, Jun 13, 2020 at 10:25 AM Denton Liu <liu.denton@xxxxxxxxx> wrote: > > > [...] > > > Teach `git checkout --worktree`, allowing users to checkout files > > > directly into the worktree without affecting the index. > > > > > > Signed-off-by: Denton Liu <liu.denton@xxxxxxxxx> > > > --- > > > diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt > > > @@ -264,6 +266,12 @@ When switching branches with `--merge`, staged changes may be lost. > > > +-W:: > > > +--worktree:: > > > + When writing contents, only modify files in the worktree. Do not > > > + modify the index. This option is essentially a no-op when used > > > + without a `<tree-ish>`. > > > > Why a no-op rather than actually diagnosing that --worktree makes no > > sense in that case and erroring out? > > I decided on this behaviour because I assumed that an empty > `git checkout` has `git restore` behaviour but I guess I was mistaken. > I'll change it to error out. ...Disregard the above. I misread your comments. I thought about it some more and I think that the real bug is in how I phrased it in the documentation. I meant that --worktree itself was essentially no-op, not the whole checkout operation. I think that it makes sense to allow this behaviour. The documentation states that we only modify files in the worktree. So if we do `git checkout --worktree <path>`, we should overwrite the worktree with the index. This should be exactly the same as running `git checkout <path>`. However, one additonal behaviour I should implement is running `git checkout --worktree` should behave like running `git checkout .`. So this would make --worktree not a no-op without a tree-ish.
