git/builtin/worktree.c, branch v2.20.2

worktree: rename is_worktree_locked to worktree_lock_reason

2018-10-31T02:41:47Z

A function prefixed with 'is_' would be expected to return a boolean, however this function returns a string. Signed-off-by: Nickolai Belakovski Signed-off-by: Junio C Hamano

worktree: delete .git/worktrees if empty after 'remove'

2018-08-30T16:28:02Z

For cleanliness, "git worktree prune" deletes the .git/worktrees directory if it is empty after pruning is complete. For consistency, make "git worktree remove " likewise delete .git/worktrees if it is empty after the removal. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: teach 'remove' to override lock when --force given twice

2018-08-30T16:28:02Z

For consistency with "add -f -f" and "move -f -f" which override the lock on a worktree, allow "remove -f -f" to do so, as well, as a convenience. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: teach 'move' to override lock when --force given twice

2018-08-30T16:28:02Z

For consistency with "add -f -f", which allows a missing but locked worktree path to be re-used, allow "move -f -f" to override a lock, as well, as a convenience. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: teach 'add' to respect --force for registered but missing path

2018-08-30T16:28:02Z

For safety, "git worktree add " will refuse to add a new worktree at if is already associated with a worktree entry, even if is missing (for instance, has been deleted or resides on non-mounted removable media or network share). The typical way to re-create a worktree at in such a situation is either to prune all "broken" entries ("git worktree prune") or to selectively remove the worktree entry manually ("git worktree remove "). However, neither of these approaches ("prune" nor "remove") is especially convenient, and they may be unsuitable for scripting when a tool merely wants to re-use a worktree if it exists or create it from scratch if it doesn't (much as a tool might use "mkdir -p" to re-use or create a directory). Therefore, teach 'add' to respect --force as a convenient way to re-use a path already associated with a worktree entry if the path is non-existent. For a locked worktree, require --force to be specified twice. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: disallow adding same path multiple times

2018-08-30T16:28:02Z

A given path should only ever be associated with a single registered worktree. This invariant is enforced by refusing to create a new worktree at a given path if that path already exists. For example: $ git worktree add -q --detach foo $ git worktree add -q --detach foo fatal: 'foo' already exists However, the check can be fooled, and the invariant broken, if the path is missing. Continuing the example: $ rm -fr foo $ git worktree add -q --detach foo $ git worktree list ... eadebfe [master] .../foo eadebfe (detached HEAD) .../foo eadebfe (detached HEAD) This "corruption" leads to the unfortunate situation in which the worktree can not be removed: $ git worktree remove foo fatal: validation failed, cannot remove working tree: '.../foo' does not point back to '.git/worktrees/foo' Nor can the bogus entry be pruned: $ git worktree prune -v $ git worktree list ... eadebfe [master] .../foo eadebfe (detached HEAD) .../foo eadebfe (detached HEAD) without first deleting the worktree directory manually: $ rm -fr foo $ git worktree prune -v Removing .../foo: gitdir file points to non-existent location Removing .../foo1: gitdir file points to non-existent location $ git worktree list ... eadebfe [master] or by manually deleting the worktree entry in .git/worktrees. To address this problem, upgrade "git worktree add" validation to allow worktree creation only if the given path is not already associated with an existing worktree (even if the path itself is non-existent), thus preventing such bogus worktree entries from being created in the first place. Reported-by: Jeff King Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: prepare for more checks of whether path can become worktree

2018-08-30T16:28:02Z

Certain conditions must be met for a path to be a valid candidate as the location of a new worktree; for instance, the path must not exist or must be an empty directory. Although the number of conditions is small, new conditions will soon be added so factor out the existing checks into a separate function to avoid further bloating add_worktree(). Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: generalize delete_git_dir() to reduce code duplication

2018-08-30T16:28:02Z

prune_worktrees() and delete_git_dir() both remove worktree administrative entries from .git/worktrees, and their implementations are nearly identical. The only difference is that prune_worktrees() is also capable of removing a bogus non-worktree-related file from .git/worktrees. Simplify by extending delete_git_dir() to handle the little bit of extra functionality needed by prune_worktrees(), and drop the effectively duplicate code from the latter. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: move delete_git_dir() earlier in file for upcoming new callers

2018-08-30T16:28:02Z

This is a pure code movement to avoid having to forward-declare the function when new callers are subsequently added. Signed-off-by: Eric Sunshine Signed-off-by: Junio C Hamano

worktree: add --quiet option

2018-08-17T22:18:01Z

Add the '--quiet' option to git worktree, as for the other git commands. 'add' is the only command affected by it since all other commands, except 'list', are currently silent by default. [jc: appiled trivial fix-up to keep the tests from touching outside the scratch area] Helped-by: Martin Ågren Helped-by: Duy Nguyen Helped-by: Eric Sunshine Signed-off-by: Elia Pinto Signed-off-by: Junio C Hamano