Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

[Eric Sunshine <sunshine@sunshineco.com>]

On Tue, Sep 4, 2018 at 6:36 PM Junio C Hamano <gitster@pobox.com> wrote:
> * es/worktree-forced-ops-fix (2018-08-30) 9 commits
>  - worktree: delete .git/worktrees if empty after 'remove'
>  - worktree: teach 'remove' to override lock when --force given twice
>  - worktree: teach 'move' to override lock when --force given twice
>  - worktree: teach 'add' to respect --force for registered but missing path
>  - worktree: disallow adding same path multiple times
>  - worktree: prepare for more checks of whether path can become worktree
>  - worktree: generalize delete_git_dir() to reduce code duplication
>  - worktree: move delete_git_dir() earlier in file for upcoming new callers
>  - worktree: don't die() in library function find_worktree()
>
>  Various subcommands of "git worktree" take '--force' but did not
>  behave sensibly, which has been corrected.

This description mischaracterizes what these changes are about. The
primary intent of this series is to fix a bug in which the same path
can be registered under multiple worktree entries.

As for --force, it worked perfectly fine for the couple git-worktree
subcommands which accepted it. The patches in this series dealing
with --force are merely extending it to other subcommands or to other
use-cases.

So, perhaps rewrite this description like this:

    Fix a bug in which the same path could be registered under
    multiple worktree entries if the patch was missing (for instance,
    was removed manually).

    Also, as a convenience, expand the number of cases in which
    --force is applicable.