Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)
- Date: Wed, 5 Sep 2018 05:14:13 -0400
- From: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
- Subject: Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)
On Tue, Sep 4, 2018 at 6:36 PM Junio C Hamano <gitster@xxxxxxxxx> 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
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.