Re: [PATCH v2 23/32] prune: strategies for linked checkouts

> One minor addition for clarification would be to mention that the 'git
> prune --worktrees' invocation applies to the main worktree:
>
>     When you are done with a linked working tree, you can simply delete
>     it. You can clean up any stale $GIT_DIR/worktrees entries via
>     `git prune --worktrees` in the main worktree.

>>> +To stop `git prune --worktrees` from deleting a specific working
>>> +directory (e.g. because it's on a portable device), you could add the
>>> +file 'locked' to $GIT_DIR/worktrees. For example, if `.git` file of
>>> +the new working directory points to `/path/main/worktrees/test-next`,
>>> +the full path of the 'locked' file would be
>>> +`/path/main/worktrees/test-next/locked`. See
>>> +linkgit:gitrepository-layout[5] for details.
>>
>> Sorry, I can't help rewriting this one too:
>>
>>         To prevent `git prune --worktrees` from deleting a
>>         $GIT_DIR/worktrees entry (which can be useful in some situations,
>>         such as when the entry's working tree is stored on a portable
>>         device), add a file named 'locked' to the entry's directory.  For
>>         example, if a linked working tree's `.git` file points to
>>         `/path/main/.git/worktrees/test-next` then a file named
>>         `/path/main/.git/worktrees/test-next/locked` will prevent the
>>         `test-next` entry from being pruned.  See
>>         linkgit:gitrepository-layout[5] for details.
>
> Each time I read this (or Duy's original), the first question that
> pops into my head is "should 'locked' be empty or have content, and if
> content, what content?" gitrepository-layout.txt does explain the
> content (if the reader bothers to chase the link), but perhaps it is
> worth an explanatory sentence here?