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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sep 5, 2018, 09:14 UTC
Message-ID: <CAPig+cTQLED6P2AWrxU=pvNc6WzO-5YVsPNh3fg28LdZqU15AA@mail.gmail.com>
In-Reply-To: <xmqqmusw6gbo.fsf@gitster-ct.c.googlers.com>

On Tue, Sep 4, 2018 at 6:36 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> * 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.