summaryrefslogtreecommitdiff
path: root/t/t2028-worktree-move.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-01-07worktree: allow to (re)move worktrees with uninitialized submodulesLibravatar Nguyễn Thái Ngọc Duy1-0/+37
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/<worktree>/modules/<submodule> 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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: delete .git/worktrees if empty after 'remove'Libravatar Eric Sunshine1-0/+12
For cleanliness, "git worktree prune" deletes the .git/worktrees directory if it is empty after pruning is complete. For consistency, make "git worktree remove <path>" likewise delete .git/worktrees if it is empty after the removal. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: teach 'remove' to override lock when --force given twiceLibravatar Eric Sunshine1-0/+10
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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: teach 'move' to override lock when --force given twiceLibravatar Eric Sunshine1-0/+14
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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: don't die() in library function find_worktree()Libravatar Eric Sunshine1-0/+8
Callers don't expect library function find_worktree() to die(); they expect it to return the named worktree if found, or NULL if not. Although find_worktree() itself never invokes die(), it calls real_pathdup() with 'die_on_error' incorrectly set to 'true', thus will die() indirectly if the user-provided path is not to real_pathdup()'s liking. This can be observed, for instance, with any git-worktree command which searches for an existing worktree: $ git worktree unlock foo fatal: 'foo' is not a working tree $ git worktree unlock foo/bar fatal: Invalid path '.../foo': No such file or directory The first error message is the expected one from "git worktree unlock" not finding the specified worktree; the second is from find_worktree() invoking real_pathdup() incorrectly and die()ing prematurely. Aside from the inconsistent error message between the two cases, this bug hasn't otherwise been a serious problem since existing callers all die() anyhow when the worktree can't be found. However, that may not be true of callers added in the future, so fix find_worktree() to avoid die()ing. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05t2028: tighten grep expression to make "move worktree" test more robustLibravatar Eric Sunshine1-4/+3
Following a rename of worktree "source" to "destination", the "move worktree" test uses grep to verify that the output of "git worktree list --porcelain" does not contain "source" (and does contain "destination"). Unfortunately, the grep expression is too loose and can match unexpectedly. For example, if component of the test trash directory path matches "source" (e.g. "/home/me/sources/git/t/trash*"), then the test will be fooled into thinking that "source" still exists. Tighten the expression to avoid such accidental matches. While at it, drop an unused variable ("toplevel") from the test and tighten a similarly too-loose expression in a related test. Reported-by: Jens Krüger <Jens.Krueger@frm2.tum.de> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-06t2028: fix minor error and issues in newly-added "worktree move" testsLibravatar Eric Sunshine1-10/+9
Recently-added "git worktree move" tests include a minor error and a few small issues. Specifically: * checking non-existence of wrong file ("source" instead of "destination") * unneeded redirect (">empty") * unused variable ("toplevel") * restoring a worktree location by means of a separate test somewhat distant from the test which moved it rather than using test_when_finished() to restore it in a self-contained fashion * having git command on the left-hand-side of a pipe ("git foo | grep") Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Acked-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12worktree remove: allow it when $GIT_WORK_TREE is already goneLibravatar Nguyễn Thái Ngọc Duy1-0/+17
"git worktree remove" basically consists of two things - delete $GIT_WORK_TREE - delete $GIT_DIR (which is $SUPER_GIT_DIR/worktrees/something) If $GIT_WORK_TREE is already gone for some reason, we should be able to finish the job by deleting $GIT_DIR. Two notes: - $GIT_WORK_TREE _can_ be missing if the worktree is locked. In that case we must not delete $GIT_DIR because the real $GIT_WORK_TREE may be in a usb stick somewhere. This is already handled because we check for lock first. - validate_worktree() is still called because it may do more checks in future (and it already does something else, like checking main worktree, but that's irrelevant in this case) Noticed-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12worktree remove: new commandLibravatar Nguyễn Thái Ngọc Duy1-0/+30
This command allows to delete a worktree. Like 'move' you cannot remove the main worktree, or one with submodules inside [1]. For deleting $GIT_WORK_TREE, Untracked files or any staged entries are considered precious and therefore prevent removal by default. Ignored files are not precious. When it comes to deleting $GIT_DIR, there's no "clean" check because there should not be any valuable data in there, except: - HEAD reflog. There is nothing we can do about this until somebody steps up and implements the ref graveyard. - Detached HEAD. Technically it can still be recovered. Although it may be nice to warn about orphan commits like 'git checkout' does. [1] We do 'git status' with --ignore-submodules=all for safety anyway. But this needs a closer look by submodule people before we can allow deletion. For example, if a submodule is totally clean, but its repo not absorbed to the main .git dir, then deleting worktree also deletes the valuable .submodule repo too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12worktree move: accept destination as directoryLibravatar Nguyễn Thái Ngọc Duy1-0/+11
Similar to "mv a b/", which is actually "mv a b/a", we extract basename of source worktree and create a directory of the same name at destination if dst path is a directory. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12worktree move: new commandLibravatar Nguyễn Thái Ngọc Duy1-0/+26
This command allows to relocate linked worktrees. Main worktree cannot (yet) be moved. There are two options to move the main worktree, but both have complications, so it's not implemented yet. Anyway the options are: - convert the main worktree to a linked one and move it away, leave the git repository where it is. The repo essentially becomes bare after this move. - move the repository with the main worktree. The tricky part is make sure all file descriptors to the repository are closed, or it may fail on Windows. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-08worktree: add "unlock" commandLibravatar Nguyễn Thái Ngọc Duy1-0/+14
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-08worktree: add "lock" commandLibravatar Nguyễn Thái Ngọc Duy1-0/+48
Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>