"git worktree add <path>" performs various checks before approving <path> as a valid location for the new worktree. One such check is asking whether <path> is already a registered worktree. Unfortunately, this check can be fooled by the magic suffix matching performed by find_worktree() as a convenience to minimize typing when identifying worktrees on the command-line. That the check could be fooled was a known issue, and a special-case work-around for accidental matching against the main worktree was already in place even when the validation check was first implemented[1]. Since that time, an additional case of accidental suffix matching has been reported[2], which was not covered by the existing special case. Rather than adding more band-aids to the validation to work around magic matching performed by find_worktree(), this patch series fixes the problem once and for all by locating a worktree deterministically based only on pathname. [1]: https://lore.kernel.org/git/CAPig+cQh8hxeoVjLHDKhAcZVQPpPT5v0AUY8gsL9=qfJ7z-L2A@xxxxxxxxxxxxxx/ [2]: https://lore.kernel.org/git/0308570E-AAA3-43B8-A592-F4DA9760DBED@xxxxxxxxxxxx/ Eric Sunshine (3): worktree: improve find_worktree() documentation worktree: add utility to find worktree by pathname worktree: don't allow "add" validation to be fooled by suffix matching builtin/worktree.c | 9 +-------- t/t2400-worktree-add.sh | 9 +++++++++ worktree.c | 16 ++++++++++------ worktree.h | 20 ++++++++++++++++++-- 4 files changed, 38 insertions(+), 16 deletions(-) -- 2.25.1.526.gf05a752211
