summaryrefslogtreecommitdiff
path: root/Documentation/git-worktree.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-12-21worktree: teach `repair` to fix multi-directional breakageLibravatar Eric Sunshine1-0/+5
`git worktree repair` knows how to repair the two-way links between the repository and a worktree as long as a link in one or the other direction is sound. For instance, if a linked worktree is moved (without using `git worktree move`), repair is possible because the worktree still knows the location of the repository even though the repository no longer knows where the worktree is. Similarly, if the repository is moved, repair is possible since the repository still knows the locations of the worktrees even though the worktrees no longer know where the repository is. However, if both the repository and the worktrees are moved, then links are severed in both directions, and no repair is possible. This is the case even when the new worktree locations are specified as arguments to `git worktree repair`. The reason for this limitation is twofold. First, when `repair` consults the worktree's gitfile (/path/to/worktree/.git) to determine the corresponding <repo>/worktrees/<id>/gitdir file to fix, <repo> is the old path to the repository, thus it is unable to fix the `gitdir` file at its new location since it doesn't know where it is. Second, when `repair` consults <repo>/worktrees/<id>/gitdir to find the location of the worktree's gitfile (/path/to/worktree/.git), the path recorded in `gitdir` is the old location of the worktree's gitfile, thus it is unable to repair the gitfile since it doesn't know where it is. Fix these shortcomings by teaching `repair` to attempt to infer the new location of the <repo>/worktrees/<id>/gitdir file when the location recorded in the worktree's gitfile has become stale but the file is otherwise well-formed. The inference is intentionally simple-minded. For each worktree path specified as an argument, `git worktree repair` manually reads the ".git" gitfile at that location and, if it is well-formed, extracts the <id>. It then searches for a corresponding <id> in <repo>/worktrees/ and, if found, concludes that there is a reasonable match and updates <repo>/worktrees/<id>/gitdir to point at the specified worktree path. In order for <repo> to be known, `git worktree repair` must be run in the main worktree or bare repository. `git worktree repair` first attempts to repair each incoming /path/to/worktree/.git gitfile to point at the repository, and then attempts to repair outgoing <repo>/worktrees/<id>/gitdir files to point at the worktrees. This sequence was chosen arbitrarily when originally implemented since the order of fixes is immaterial as long as one side of the two-way link between the repository and a worktree is sound. However, for this new repair technique to work, the order must be reversed. This is because the new inference mechanism, when it is successful, allows the outgoing <repo>/worktrees/<id>/gitdir file to be repaired, thus fixing one side of the two-way link. Once that side is fixed, the other side can be fixed by the existing repair mechanism, hence the order of repairs is now significant. Two safeguards are employed to avoid hijacking a worktree from a different repository if the user accidentally specifies a foreign worktree as an argument. The first, as described above, is that it requires an <id> match between the repository and the worktree. That itself is not foolproof for preventing hijack, so the second safeguard is that the inference will only kick in if the worktree's /path/to/worktree/.git gitfile does not point at a repository. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-12worktree: teach `list` to annotate locked worktreeLibravatar Rafael Silva1-2/+3
The "git worktree list" shows the absolute path to the working tree, the commit that is checked out and the name of the branch. It is not immediately obvious which of the worktrees, if any, are locked. "git worktree remove" refuses to remove a locked worktree with an error message. If "git worktree list" told which worktrees are locked in its output, the user would not even attempt to remove such a worktree, or would realize that "git worktree remove -f -f <path>" is required. Teach "git worktree list" to append "locked" to its output. The output from the command becomes like so: $ git worktree list /path/to/main abc123 [master] /path/to/worktree 456def (detached HEAD) /path/to/locked-worktree 123abc (detached HEAD) locked Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Rafael Silva <rafaeloliveira.cs@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18Merge branch 'es/wt-add-detach'Libravatar Junio C Hamano1-0/+13
"git worktree add" learns that the "-d" is a synonym to "--detach" option to create a new worktree without being on a branch. * es/wt-add-detach: git-worktree.txt: discuss branch-based vs. throwaway worktrees worktree: teach `add` to recognize -d as shorthand for --detach git-checkout.txt: document -d short option for --detach
2020-09-06git-worktree.txt: discuss branch-based vs. throwaway worktreesLibravatar Eric Sunshine1-0/+12
By default, `git worktree add` creates a new worktree associated with a particular branch (which may have been created automatically if not specified explicitly on the command-line). It is also convenient to create throwaway worktrees not associated with any branch, which can be handy when making experimental changes or doing testing. However, the latter use-case may not be obvious to newcomers since the high-level description of worktrees talks only about checking out "more than one branch at a time". Therefore, enhance the description to to discuss both use-cases. A secondary goal of highlighting the distinction between branch-based and throwaway worktrees is to help newcomers understand that the simplest form `git worktree add <path>` automatically creates a new branch. Stating this early in the description, may help newcomers avoid creating branches without realizing they are doing so, and later wondering why `git branch --list` shows branches the user did not intentionally create. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-06worktree: teach `add` to recognize -d as shorthand for --detachLibravatar Eric Sunshine1-0/+1
Like `git switch` and `git checkout`, `git worktree add` can check out a branch or set up a detached HEAD. However, unlike those other commands, `git worktree add` does not understand -d as shorthand for --detach, which may confound users accustomed to using -d for this purpose. Address this shortcoming by teaching `add` to recognize -d for --detach, thus bringing it in line with the other commands. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31worktree: teach "repair" to fix outgoing links to worktreesLibravatar Eric Sunshine1-3/+11
The .git/worktrees/<id>/gitdir file points at the location of a linked worktree's .git file. Its content must be of the form /path/to/worktree/.git (from which the location of the worktree itself can be derived by stripping the "/.git" suffix). If the gitdir file is deleted or becomes corrupted or outdated, then Git will be unable to find the linked worktree. An easy way for the gitdir file to become outdated is for the user to move the worktree manually (without using "git worktree move"). Although it is possible to manually update the gitdir file to reflect the new linked worktree location, doing so requires a level of knowledge about worktree internals beyond what a user should be expected to know offhand. Therefore, teach "git worktree repair" how to repair broken or outdated .git/worktrees/<id>/gitdir files automatically. (For this to work, the command must either be invoked from within the worktree whose gitdir file requires repair, or from within the main or any linked worktree by providing the path of the broken worktree as an argument to "git worktree repair".) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31worktree: teach "repair" to fix worktree back-links to main worktreeLibravatar Eric Sunshine1-1/+9
The .git file in a linked worktree is a "gitfile" which points back to the .git/worktrees/<id> entry in the main worktree or bare repository. If a worktree's .git file is deleted or becomes corrupted or outdated, then the linked worktree won't know how to find the repository or any of its own administrative files (such as 'index', 'HEAD', etc.). An easy way for the .git file to become outdated is for the user to move the main worktree or bare repository. Although it is possible to manually update each linked worktree's .git file to reflect the new repository location, doing so requires a level of knowledge about worktree internals beyond what a user should be expected to know offhand. Therefore, teach "git worktree repair" how to repair broken or outdated worktree .git files automatically. (For this to work, the command must be invoked from within the main worktree or bare repository, or from within a worktree which has not become disconnected from the repository -- such as one which was created after the repository was moved.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27worktree: add skeleton "repair" commandLibravatar Eric Sunshine1-0/+6
Worktree administrative files can become corrupted or outdated due to external factors. Although, it is often possible to recover from such situations by hand-tweaking these files, doing so requires intimate knowledge of worktree internals. While information necessary to make such repairs manually can be obtained from git-worktree.txt and gitrepository-layout.txt, we can assist users more directly by teaching git-worktree how to repair its administrative files itself (at least to some extent). Therefore, add a "git worktree repair" command which attempts to correct common problems which may arise due to factors beyond Git's control. At this stage, the "repair" command is a mere skeleton; subsequent commits will flesh out the functionality. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03git-worktree.txt: link to man pages when citing other Git commandsLibravatar Eric Sunshine1-2/+3
When citing other Git commands, rather than merely formatting them with a fixed-width typeface, improve the reader experience by linking to them directly via `linkgit:`. Suggested-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03git-worktree.txt: make start of new sentence more obviousLibravatar Eric Sunshine1-2/+2
When reading the rendered description of `add`, it's easy to trip over and miss the end of one sentence and the start of the next, making it seem as if they are part of the same statement, separated only by a dash: ... specific files such as HEAD, index, etc. - may also be specified as <commit-ish>; it is synonymous with... This can be particularly confusing since the thoughts expressed by the two sentences are unrelated. Reduce the likelihood of confusion by making it obvious that the two sentences are distinct. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03git-worktree.txt: fix minor grammatical issuesLibravatar Eric Sunshine1-10/+10
Fix a few grammatical problems to improve the reading experience. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03git-worktree.txt: consistently use term "working tree"Libravatar Eric Sunshine1-11/+11
As originally composed, git-worktree.txt employed a mix of "worktree" and "working tree" which was inconsistent and potentially confusing to readers. bc483285b7 (Documentation/git-worktree: consistently use term "linked working tree", 2015-07-20) undertook the task of employing the term "working tree" consistently throughout the document and avoiding "worktree" altogether for descriptive text. Since that time, some instances of "worktree" have crept back in. Continue the work of bc483285b7 by transforming these to "working tree", as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03git-worktree.txt: employ fixed-width typeface consistentlyLibravatar Eric Sunshine1-48/+48
git-worktree documentation generally does a good job of formatting literal text using a fixed-width typeface, however, some instances of unformatted literal text have crept in over time. Fix these. While at it, also fix a few incorrect typefaces resulting from wrong choice of Asciidoc quotes. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-10worktree: make "move" refuse to move atop missing registered worktreeLibravatar Eric Sunshine1-1/+3
"git worktree add" takes special care to avoid creating a new worktree at a location already registered to an existing worktree even if that worktree is missing (which can happen, for instance, if the worktree resides on removable media). "git worktree move", however, is not so careful when validating the destination location and will happily move the source worktree atop the location of a missing worktree. This leads to the anomalous situation of multiple worktrees being associated with the same path, which is expressly forbidden by design. For example: $ git clone foo.git $ cd foo $ git worktree add ../bar $ git worktree add ../baz $ rm -rf ../bar $ git worktree move ../baz ../bar $ git worktree list .../foo beefd00f [master] .../bar beefd00f [bar] .../bar beefd00f [baz] $ git worktree remove ../bar fatal: validation failed, cannot remove working tree: '.../bar' does not point back to '.git/worktrees/bar' Fix this shortcoming by enhancing "git worktree move" to perform the same additional validation of the destination directory as done by "git worktree add". While at it, add a test to verify that "git worktree move" won't move a worktree atop an existing (non-worktree) path -- a restriction which has always been in place but was never tested. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-18doc: fix typos in man pagesLibravatar Alexander Blesius1-1/+1
Signed-off-by: Alexander Blesius <alexander+git@blesius.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'nd/per-worktree-ref-iteration'Libravatar Junio C Hamano1-1/+31
The code to traverse objects for reachability, used to decide what objects are unreferenced and expendable, have been taught to also consider per-worktree refs of other worktrees as starting points to prevent data loss. * nd/per-worktree-ref-iteration: git-worktree.txt: correct linkgit command name reflog expire: cover reflog from all worktrees fsck: check HEAD and reflog from other worktrees fsck: move fsck_head_link() to get_default_heads() to avoid some globals revision.c: better error reporting on ref from different worktrees revision.c: correct a parameter name refs: new ref types to make per-worktree refs visible to all worktrees Add a place for (not) sharing stuff between worktrees refs.c: indent with tabs, not spaces
2018-11-13Merge branch 'nd/per-worktree-config'Libravatar Junio C Hamano1-0/+33
A fourth class of configuration files (in addition to the traditional "system wide", "per user in the $HOME directory" and "per repository in the $GIT_DIR/config") has been introduced so that different worktrees that share the same repository (hence the same $GIT_DIR/config file) can use different customization. * nd/per-worktree-config: worktree: add per-worktree config files t1300: extract and use test_cmp_config()
2018-11-05git-worktree.txt: correct linkgit command nameLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Noticed-by: SZEDER Gábor <szeder.dev@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-10-30Merge branch 'ah/doc-updates'Libravatar Junio C Hamano1-2/+2
Doc updates. * ah/doc-updates: doc: fix formatting in git-update-ref doc: fix indentation of listing blocks in gitweb.conf.txt doc: fix descripion for 'git tag --format' doc: fix inappropriate monospace formatting doc: fix ASCII art tab spacing doc: clarify boundaries of 'git worktree list --porcelain'
2018-10-23doc: clarify boundaries of 'git worktree list --porcelain'Libravatar Andreas Heiduk1-2/+2
Defined delimiters for 'git worktree list --porcelain' make the format easier to parse in scripts. For example sed -n '/^worktree ID$/,/^$/p' extracts only the information for the worktree 'ID'. The format did not changed since [1], only the guaranty is added. [1] bb9c03b82a (worktree: add 'list' command, 2015-10-08) Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22refs: new ref types to make per-worktree refs visible to all worktreesLibravatar Nguyễn Thái Ngọc Duy1-1/+14
One of the problems with multiple worktree is accessing per-worktree refs of one worktree from another worktree. This was sort of solved by multiple ref store, where the code can open the ref store of another worktree and has access to the ref space of that worktree. The problem with this is reporting. "HEAD" in another ref space is also called "HEAD" like in the current ref space. In order to differentiate them, all the code must somehow carry the ref store around and print something like "HEAD from this ref store". But that is not feasible (or possible with a _lot_ of work). With the current design, we pass a reference around as a string (so called "refname"). Extending this design to pass a string _and_ a ref store is a nightmare, especially when handling extended SHA-1 syntax. So we do it another way. Instead of entering a separate ref space, we make refs from other worktrees available in the current ref space. So "HEAD" is always HEAD of the current worktree, but then we can have "worktrees/blah/HEAD" to denote HEAD from a worktree named "blah". This syntax coincidentally matches the underlying directory structure which makes implementation a bit easier. The main worktree has to be treated specially because well... it's special from the beginning. So HEAD from the main worktree is acccessible via the name "main-worktree/HEAD" instead of "worktrees/main/HEAD" because "main" could be just another secondary worktree. This patch also makes it possible to specify refs from one worktree in another one, e.g. git log worktrees/foo/HEAD Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22worktree: add per-worktree config filesLibravatar Nguyễn Thái Ngọc Duy1-0/+33
A new repo extension is added, worktreeConfig. When it is present: - Repository config reading by default includes $GIT_DIR/config _and_ $GIT_DIR/config.worktree. "config" file remains shared in multiple worktree setup. - The special treatment for core.bare and core.worktree, to stay effective only in main worktree, is gone. These config settings are supposed to be in config.worktree. This extension is most useful in multiple worktree setup because you now have an option to store per-worktree config (which is either .git/config.worktree for main worktree, or .git/worktrees/xx/config.worktree for linked ones). This extension can be used in single worktree mode, even though it's pretty much useless (but this can happen after you remove all linked worktrees and move back to single worktree). "git config" reads from both "config" and "config.worktree" by default (i.e. without either --user, --file...) when this extension is present. Default writes still go to "config", not "config.worktree". A new option --worktree is added for that (*). Since a new repo extension is introduced, existing git binaries should refuse to access to the repo (both from main and linked worktrees). So they will not misread the config file (i.e. skip the config.worktree part). They may still accidentally write to the config file anyway if they use with "git config --file <path>". This design places a bet on the assumption that the majority of config variables are shared so it is the default mode. A safer move would be default writes go to per-worktree file, so that accidental changes are isolated. (*) "git config --worktree" points back to "config" file when this extension is not present and there is only one worktree so that it works in any both single and multiple worktree setups. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07Add a place for (not) sharing stuff between worktreesLibravatar Nguyễn Thái Ngọc Duy1-1/+18
When multiple worktrees are used, we need rules to determine if something belongs to one worktree or all of them. Instead of keeping adding rules when new stuff comes (*), have a generic rule: - Inside $GIT_DIR, which is per-worktree by default, add $GIT_DIR/common which is always shared. New features that want to share stuff should put stuff under this directory. - Inside refs/, which is shared by default except refs/bisect, add refs/worktree/ which is per-worktree. We may eventually move refs/bisect to this new location and remove the exception in refs code. (*) And it may also include stuff from external commands which will have no way to modify common/per-worktree rules. 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: teach 'remove' to override lock when --force given twiceLibravatar Eric Sunshine1-0/+1
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/+3
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: teach 'add' to respect --force for registered but missing pathLibravatar Eric Sunshine1-2/+6
For safety, "git worktree add <path>" will refuse to add a new worktree at <path> if <path> is already associated with a worktree entry, even if <path> 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 <path> 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 <path>"). 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 <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-17worktree: add --quiet optionLibravatar Elia Pinto1-0/+4
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 <martin.agren@gmail.com> Helped-by: Duy Nguyen <pclouds@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11checkout & worktree: introduce checkout.defaultRemoteLibravatar Ævar Arnfjörð Bjarmason1-0/+9
Introduce a checkout.defaultRemote setting which can be used to designate a remote to prefer (via checkout.defaultRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to use this workflow to checkout a repository and create a topic branch, then get back to a "master" as retrieved from upstream: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git checkout master ) That will output: Branch 'master' set up to track remote branch 'master' from 'origin'. Switched to a new branch 'master' But as soon as a new remote is added (e.g. just to inspect something from someone else) the DWIMery goes away: ( cd /tmp && rm -rf tbdiff && git clone git@github.com:trast/tbdiff.git && cd tbdiff && git branch -m topic && git remote add avar git@github.com:avar/tbdiff.git && git fetch avar && git checkout master ) Will output (without the advice output added earlier in this series): error: pathspec 'master' did not match any file(s) known to git. The new checkout.defaultRemote config allows me to say that whenever that ambiguity comes up I'd like to prefer "origin", and it'll still work as though the only remote I had was "origin". Also adjust the advice.checkoutAmbiguousRemoteBranchName message to mention this new config setting to the user, the full output on my git.git is now (the last paragraph is new): $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> hint: hint: If you'd like to always have checkouts of an ambiguous <name> prefer hint: one remote, e.g. the 'origin' remote, consider setting hint: checkout.defaultRemote=origin in your config. I considered splitting this into checkout.defaultRemote and worktree.defaultRemote, but it's probably less confusing to break our own rules that anything shared between config should live in core.* than have two config settings, and I couldn't come up with a short name under core.* that made sense (core.defaultRemoteForCheckout?). See also 70c9ac2f19 ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature to begin with, and 4e85333197 ("worktree: make add <path> <branch> dwim", 2017-11-26) which added it to git-worktree. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23Merge branch 'tg/worktree-add-existing-branch'Libravatar Junio C Hamano1-2/+7
"git worktree add" learned to check out an existing branch. * tg/worktree-add-existing-branch: worktree: teach "add" to check out existing branches worktree: factor out dwim_branch function worktree: improve message when creating a new worktree worktree: remove extra members from struct add_opts
2018-05-08Merge branch 'sb/worktree-remove-opt-force'Libravatar Junio C Hamano1-1/+1
"git worktree remove" learned that "-f" is a shorthand for "--force" option, just like for "git worktree add". * sb/worktree-remove-opt-force: worktree: accept -f as short for --force for removal
2018-04-30worktree: teach "add" to check out existing branchesLibravatar Thomas Gummerer1-2/+7
Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given. However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes. As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here. We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'es/worktree-docs'Libravatar Junio C Hamano1-9/+9
Doc updates. * es/worktree-docs: git-worktree.txt: unify command-line prompt in example blocks git-worktree.txt: recommend 'git worktree remove' over manual deletion
2018-04-18worktree: accept -f as short for --force for removalLibravatar Stefan Beller1-1/+1
Many commands support a "--force" option, frequently abbreviated as "-f", however, "git worktree remove"'s hand-rolled OPT_BOOL forgets to recognize the short form, despite git-worktree.txt documenting "-f" as supported. Replace OPT_BOOL with OPT__FORCE, which provides "-f" for free, and makes 'remove' consistent with 'add' option parsing (which also specifies the PARSE_OPT_NOCOMPLETE flag). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09git-worktree.txt: unify command-line prompt in example blocksLibravatar Eric Sunshine1-2/+2
The command-line prompt in the "EXAMPLES" section is "$", however, examples in the 'git worktree list' section (oddly) use "S" as a prompt. Fix this inconsistency by settling on "$" as prompt in all examples. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09git-worktree.txt: recommend 'git worktree remove' over manual deletionLibravatar Eric Sunshine1-7/+7
When cc73385cf6 (worktree remove: new command, 2018-02-12) implemented and documented 'git worktree remove', it forgot to update existing instructions suggesting manual deletion. Fix this oversight by recommending 'git worktree remove' instead. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14Merge branch 'nd/worktree-move'Libravatar Junio C Hamano1-15/+19
"git worktree" learned move and remove subcommands. * nd/worktree-move: t2028: fix minor error and issues in newly-added "worktree move" tests worktree remove: allow it when $GIT_WORK_TREE is already gone worktree remove: new command worktree move: refuse to move worktrees with submodules worktree move: accept destination as directory worktree move: new command worktree.c: add update_worktree_location() worktree.c: add validate_worktree()
2018-02-16git-worktree.txt: fix indentation of example and text of 'add' commandLibravatar Eric Sunshine1-0/+1
When 4e85333197 (worktree: make add <path> <branch> dwim, 2017-11-26) added an example command in a literal code block, it neglected to insert a mandatory "+" line before the block. This omission resulted in both the literal code block and the (existing) paragraph following the block to be outdented, even though they should be indented under the 'add' sub-command along with the rest of the text pertaining to that command. Furthermore, the mandatory "+" line separating the code block from the following text got rendered as a leading character on the line ("+ If <commit-ish>...") rather than being treated as a formatting directive. Fix these problems by adding the missing "+" line before the example code block. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-16git-worktree.txt: fix missing ")" typoLibravatar Eric Sunshine1-2/+2
Add the closing ")" to a parenthetical phrase introduced by 4e85333197 (worktree: make add <path> <branch> dwim, 2017-11-26). While at it, add a missing ":" at the end of the same sentence since it precedes an example literal command block. Reported-by: Mike Nordell <tamlin.thefirst@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12worktree remove: new commandLibravatar Nguyễn Thái Ngọc Duy1-9/+12
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: refuse to move worktrees with submodulesLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Submodules contains .git files with relative paths. After a worktree move, these files need to be updated or they may point to nowhere. This is a bandage patch to make sure "worktree move" don't break people's worktrees by accident. When .git file update code is in place, this validate_no_submodules() could be removed. 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-6/+7
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>
2018-01-11Documentation/git-worktree.txt: add missing `Libravatar Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06add worktree.guessRemote config optionLibravatar Thomas Gummerer1-0/+3
Some users might want to have the --guess-remote option introduced in the previous commit on by default, so they don't have to type it out every time they create a new worktree. Add a config option worktree.guessRemote that allows users to configure the default behaviour for themselves. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06worktree: add --guess-remote flag to add subcommandLibravatar Thomas Gummerer1-0/+7
Currently 'git worktree add <path>' creates a new branch named after the basename of the <path>, that matches the HEAD of whichever worktree we were on when calling "git worktree add <path>". It's sometimes useful to have 'git worktree add <path> behave more like the dwim machinery in 'git checkout <new-branch>', i.e. check if the new branch name, derived from the basename of the <path>, uniquely matches the branch name of a remote-tracking branch, and if so check out that branch and set the upstream to the remote-tracking branch. Add a new --guess-remote option that enables exactly that behaviour. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27worktree: make add <path> <branch> dwimLibravatar Thomas Gummerer1-0/+8
Currently 'git worktree add <path> <branch>', errors out when 'branch' is not a local branch. It has no additional dwim'ing features that one might expect. Make it behave more like 'git checkout <branch>' when the branch doesn't exist locally, but a remote tracking branch uniquely matches the desired branch name, i.e. create a new branch from the remote tracking branch and set the upstream to the remote tracking branch. As 'git worktree add' currently just dies in this situation, there are no backwards compatibility worries when introducing this feature. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27worktree: add --[no-]track option to the add subcommandLibravatar Thomas Gummerer1-0/+6
Currently 'git worktree add' sets up tracking branches if '<branch>' is a remote tracking branch, and doesn't set them up otherwise, as is the default for 'git branch'. This may or may not be what the user wants. Allow overriding this behaviour with a --[no-]track flag that gets passed through to 'git branch'. We already respect branch.autoSetupMerge, as 'git worktree' just calls 'git branch' internally. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27worktree: add can be created from any commit-ishLibravatar Thomas Gummerer1-10/+10
Currently 'git worktree add' is documented to take an optional <branch> argument, which is checked out in the new worktree. However it is more generally possible to use a commit-ish as the optional argument, and check that out into the new worktree. Document that this is a possibility, as new users of git worktree add might find it helpful. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20worktree add: add --lock optionLibravatar Nguyễn Thái Ngọc Duy1-1/+6
As explained in the document. This option has an advantage over the command sequence "git worktree add && git worktree lock": there will be no gap that somebody can accidentally "prune" the new worktree (or soon, explicitly "worktree remove" it). "worktree add" does keep a lock on while it's preparing the worktree. If --lock is specified, this lock remains after the worktree is created. Suggested-by: David Taylor <David.Taylor@dell.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-24Merge branch 'bc/worktree-doc-fix-detached'Libravatar Junio C Hamano1-1/+1
Doc update. * bc/worktree-doc-fix-detached: Documentation: correctly spell git worktree --detach
2017-02-22Documentation: correctly spell git worktree --detachLibravatar brian m. carlson1-1/+1
The option is “--detach”, but we accidentally spelled it “--detached” at one point in the man page. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reported-by: Casey Rodarmor <casey@rodarmor.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>