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

Merge branch 'ms/worktree-add-atomic-mkdir'

2019-04-09T17:14:24Z

"git worktree add" used to do a "find an available name with stat and then mkdir", which is race-prone. This has been fixed by using mkdir and reacting to EEXIST in a loop. * ms/worktree-add-atomic-mkdir: worktree: fix worktree add race

worktree: fix worktree add race

2019-03-12T06:56:11Z

Git runs a stat loop to find a worktree name that's available and then does mkdir on the found name. Turn it to mkdir loop to avoid another invocation of worktree add finding the same free name and creating the directory first. Signed-off-by: Michal Suchanek Acked-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

trace2:data: add trace2 hook classification

2019-02-22T23:28:21Z

Classify certain child processes as hooks. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

worktree: allow to (re)move worktrees with uninitialized submodules

2019-01-07T17:26:33Z

Uninitialized submodules have nothing valueable for us to be worried about. They are just SHA-1. Let "worktree remove" and "worktree move" continue in this case so that people can still use multiple worktrees on repos with optional submodules that are never populated, like sha1collisiondetection in git.git when checked out by doc-diff script. Note that for "worktree remove", it is possible that a user initializes a submodule (*), makes some commits (but not push), then deinitializes it. At that point, the submodule is unpopulated, but the precious new commits are still in $GIT_COMMON_DIR/worktrees//modules/ directory and we should not allow removing the worktree or we lose those commits forever. The new directory check is added to prevent this. (*) yes they are screwed anyway by doing this since "git submodule" would add submodule.* in $GIT_COMMON_DIR/config, which is shared across multiple worktrees. But it does not mean we let them be screwed even more. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

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