summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-20worktree: populate via "git reset --hard" rather than "git checkout"Libravatar Eric Sunshine1-2/+1
Now that git-worktree handles all functionality (--force, --detach, -b/-B) previously delegated to git-checkout, actual population of the new worktree can be accomplished more directly and lightweight with "git reset --hard" in place of "git checkout". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: avoid resolving HEAD unnecessarilyLibravatar Eric Sunshine1-12/+5
Now that git-worktree sets HEAD explicitly to its final value via either git-symbolic-ref or git-update-ref, rather than relying upon git-checkout to do so, the "hack" for pacifying is_git_directory() with a temporary HEAD, though still necessary, can be simplified. Since the real HEAD is now populated with its proper final value, the value of the temporary HEAD truly no longer matters, and any value which looks like an object ID is good enough to satisfy is_git_directory(). Therefore, just set the temporary HEAD to a literal value rather than going through the effort of resolving the current branch's HEAD. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: make setup of new HEAD distinct from worktree populationLibravatar Eric Sunshine1-5/+15
git-worktree currently conflates setting of HEAD in the new worktree and initial worktree population into a single git-checkout invocation which requires git-checkout to have special knowledge that it is operating on a newly created worktree. The eventual goal is to rid git-checkout of that overly-intimate knowledge. Once these operations are separate, git-worktree will no longer be able to delegate to git-branch the setting of the new worktree's HEAD to the desired branch (or commit, if detached). Therefore, make git-worktree itself responsible for setting up HEAD as either a symbolic reference, if associated with a branch, or detached, if not. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: detect branch-name/detached and error conditions locallyLibravatar Eric Sunshine1-0/+18
git-worktree currently conflates setting of HEAD in the new worktree with initial worktree population via a single git-checkout invocation, which requires git-checkout to have special knowledge that it is operating in a newly created worktree. The eventual goal is to separate these operations and rid git-checkout of that overly-intimate knowledge. Once these operations are separate, git-worktree will no longer be able to rely upon git-branch to determine the state of the worktree (branch name or detached), or to check for error conditions, such as the requested branch already checked out elsewhere, or an invalid reference. Therefore, imbue git-worktree with the intelligence to determine a branch name or detached state locally, and to perform error checking on its own. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: add_worktree: construct worktree-population command locallyLibravatar Eric Sunshine1-11/+8
The caller of add_worktree() provides it with a command to invoke to populate the new worktree. This was a useful abstraction during the conversion of "git checkout --to" functionality to "git worktree add" since git-checkout and git-worktree constructed the population command differently. However, now that "git checkout --to" has been retired, and add_worktree() has access to the options given to "worktree add", this extra indirection is no longer useful and makes the code a bit convoluted. Moreover, the eventual goal is for git-worktree to make setting of HEAD and worktree population distinct operations, whereas they are currently conflated into a single git-checkout invocation. As such, add_worktree() will eventually invoke other commands in addition to the worktree population command, so it will be doing command construction itself anyhow. Therefore, relocate construction of the worktree population command from add() to add_worktree(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: elucidate environment variables intended for child processesLibravatar Eric Sunshine1-2/+5
Take advantage of 'struct child_process.env' to make it obvious that environment variables set by add_worktree() are intended specifically for sub-commands it invokes to operate in the new worktree. We assign a local 'struct argv_array' to child_process.env, rather than utilizing the child_process.env_array 'struct argv_array', because future patches will make add_worktree() invoke additional sub-commands, and it's simpler to populate the environment array just once, whereas child_process.env_array gets cleared after each invocation, thus would require re-population for each sub-command. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: make branch creation distinct from worktree populationLibravatar Eric Sunshine1-3/+14
git-worktree currently conflates branch creation, setting of HEAD in the new worktree, and worktree population into a single sub-invocation of git-checkout, which requires git-checkout to be specially aware that it is operating in a newly-created worktree. The goal is to free git-checkout of that special knowledge, and to do so, git-worktree will eventually perform those operations separately. Thus, as a first step, rather than piggybacking on git-checkout's -b/-B ability to create a new branch at checkout time, make git-worktree responsible for branch creation itself. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: add: suppress auto-vivication with --detach and no <branch>Libravatar Eric Sunshine3-4/+18
Fix oversight where branch auto-vivication incorrectly kicks in when --detach is specified and <branch> omitted. Instead, treat: git worktree add --detach <path> as shorthand for: git worktree add --detach <path> HEAD Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: make --detach mutually exclusive with -b/-BLibravatar Eric Sunshine2-2/+14
Be consistent with git-checkout which disallows this (not particularly meaningful) combination. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: introduce options containerLibravatar Eric Sunshine1-18/+27
add_worktree() will eventually need to deal with some options itself, so introduce a structure into which options can be conveniently bundled, and pass it along to add_worktree(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: simplify new branch (-b/-B) option checkingLibravatar Eric Sunshine1-5/+8
Make 'new_branch' be the name of the new branch for both forced and non-forced cases; and add boolean 'force_new_branch' to indicate forced branch creation. This will simplify logic later on when git-worktree handles branch creation locally rather than delegating it to git-checkout as part of the worktree population phase. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20worktree: improve worktree setup messageLibravatar Eric Sunshine1-1/+1
When git-worktree creates a new worktree, it reports: Enter "<path>" (identifier <tag>) which misleadingly implies that it is setting <path> as the working directory (as if "cd <path>" had been invoked), whereas it's actually preparing the new worktree by creating its administrative files, setting HEAD, and populating it. Make this more clear by instead saying: Preparing "<path>" (identifier <tag>) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20branch: publish die_if_checked_out()Libravatar Eric Sunshine3-67/+74
git-worktree currently conflates new branch creation, setting of HEAD in the new wortkree, and worktree population into a single sub-invocation of git-checkout. However, these operations will eventually be separated, and git-worktree itself will need to be able to detect if the branch is already checked out elsewhere, rather than relying upon git-branch to make this determination, so publish die_if_checked_out(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: teach check_linked_checkout() about symbolic link HEADLibravatar Eric Sunshine2-1/+13
check_linked_checkout() only understands symref-style HEAD (i.e. "ref: refs/heads/master"), however, HEAD may also be a an actual symbolic link (on platforms which support it). To accurately detect if a branch is checked out elsewhere, it needs to handle symbolic link HEAD, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: check_linked_checkout: simplify symref parsingLibravatar Eric Sunshine1-9/+6
check_linked_checkout() only understands symref-style HEAD (i.e. "ref: refs/heads/master"), however, HEAD may also be a an actual symbolic link (on platforms which support it), thus it will need to check that style HEAD, as well (via readlink()). As a preparatory step, simplify parsing of symref-style HEAD so the actual branch check can be re-used easily for symbolic links (in an upcoming patch). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: check_linked_checkout: improve "already checked out" aestheticLibravatar Eric Sunshine1-0/+1
When check_linked_checkout() discovers that the branch is already checked out elsewhere, it emits the diagnostic: 'blorp' is already checked out at '/some/path/.git' which is misleading since "checked out at" implies the working tree, but ".git" is the location of the repository administrative files. Fix by dropping ".git" from the message. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: generalize die_if_checked_out() branch name argumentLibravatar Eric Sunshine1-7/+8
The plan is to publish die_if_checked_out() so that callers other than git-checkout can take advantage of it, however, those callers won't have access to git-checkout's "struct branch_info". Therefore, change it to accept the full name of the branch as a simple string instead. While here, also give the argument a more meaningful name ("branch" instead of "new"). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: die_if_checked_out: simplify strbuf managementLibravatar Eric Sunshine1-4/+3
There is no reason to keep the strbuf active long after its last use. By releasing it as early as possible, resource management is simplified and there is less worry about future changes resulting in a leak. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: improve die_if_checked_out() robustnessLibravatar Eric Sunshine1-7/+7
die_if_checked_out() is intended to check if the branch about to be checked out is already checked out either in the main worktree or in a linked worktree. However, if .git/worktrees directory does not exist, then it never bothers checking the main worktree, even though the specified branch might indeed be checked out there, which is fragile behavior. This hasn't been a problem in practice since the current implementation of "git worktree add" (and, earlier, "git checkout --to") always creates .git/worktrees before die_if_checked_out() is called by the child "git checkout" invocation which populates the new worktree. However, git-worktree will eventually want to call die_if_checked_out() itself rather than only doing so indirectly as a side-effect of invoking git-checkout, and reliance upon order of operations (creating .git/worktrees before checking if a branch is already checked out) is fragile. As a general function, callers should not be expected to abide by this undocumented and unwarranted restriction. Therefore, make die_if_checked_out() more robust by checking the main worktree whether .git/worktrees exists or not. While here, also move a comment explaining why die_if_checked_out()'s helper parses HEAD manually. Such information resides more naturally with the helper itself rather than at its first point of call. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: name check_linked_checkouts() more meaningfullyLibravatar Eric Sunshine1-2/+2
check_linked_checkouts() doesn't just "check" linked checkouts for "something"; specifically, it aborts the operation if the branch about to be checked out is already checked out elsewhere. Therefore, rename it to die_if_checked_out() to give a better indication of its function. The more meaningful name will be particularly important when this function is later published for use by other callers. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20checkout: avoid resolving HEAD unnecessarilyLibravatar Eric Sunshine1-3/+3
When --ignore-other-worktree is specified, we unconditionally skip the check to see if the requested branch is already checked out in a linked worktree. Since we know that we will be skipping that check, there is no need to resolve HEAD in order to detect other conditions under which we may skip the check. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20config: rename "gc.pruneWorktreesExpire" to "gc.worktreePruneExpire"Libravatar Eric Sunshine3-4/+3
As of df0b6cf (worktree: new place for "git prune --worktrees", 2015-06-29), linked worktree pruning functionality moved from "git prune --worktrees" to "git worktree prune". Rename the associated configuration variable accordingly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20Documentation/git-worktree: wordsmith worktree-related manpagesLibravatar Michael Haggerty2-11/+12
[es: reword .git/worktrees and .git/worktrees/<id>/locked descriptions] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20Documentation/config: fix stale "git prune --worktree" referenceLibravatar Michael Haggerty1-1/+1
This should have been changed to "git worktree prune" by df0b6cf (worktree: new place for "git prune --worktrees", 2015-06-29) [es: reword commit message] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20Documentation/git-worktree: fix incorrect reference to file "locked"Libravatar Michael Haggerty1-1/+1
The administrative file to suppress pruning is named "locked", not "lock". [es: don't touch unrelated "git worktree lock" command; reword commit message] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20Documentation/git-worktree: consistently use term "linked working tree"Libravatar Michael Haggerty2-23/+23
Sometimes linked working trees were called "linked working directories" or "linked worktrees". Always refer to them as "linked working trees" for consistency. [es: fix additional occurrences] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-17Documentation/git: fix stale "MULTIPLE CHECKOUT MODE" referenceLibravatar Eric Sunshine1-1/+1
This should have been changed by 93a3649 (Documentation: move linked worktree description from checkout to worktree, 2015-07-06). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16worktree: caution that this is still experimentalLibravatar Junio C Hamano1-2/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16Documentation/git-worktree: fix stale "git checkout --to" referencesLibravatar Eric Sunshine1-2/+2
These should have been changed to "git worktree add" by fc56361 (worktree: introduce "add" command, 2015-07-06. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-12Revert "checkout: retire --ignore-other-worktrees in favor of --force"Libravatar Junio C Hamano3-7/+12
This reverts commit 0d1a1517835a10818f2d40d8780a268dbb5e20ce. When trying to switch to a different branch, that happens to be checked out in another working tree, the user shouldn't have to give up the other safety measures (like protecting the local changes that overlap the difference between the branches) while defeating the "no two checkouts of the same branch" safety. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07checkout: retire --ignore-other-worktrees in favor of --forceLibravatar Eric Sunshine3-12/+7
As a safeguard, checking out a branch already checked out by a different worktree is disallowed. This behavior can be overridden with --ignore-other-worktrees, however, this option is neither obvious nor particularly discoverable. As a common safeguard override, --force is more likely to come to mind. Therefore, overload it to also suppress the check for a branch already checked out elsewhere. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07worktree: add: auto-vivify new branch when <branch> is omittedLibravatar Eric Sunshine3-4/+26
As a convenience, when <branch> is omitted from "git worktree <path> <branch>" and neither -b nor -B is used, automatically create a new branch named after <path>, as if "-b $(basename <path>)" was specified. Thus, "git worktree add ../hotfix" creates a new branch named "hotfix" and associates it with new worktree "../hotfix". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: add: make -b/-B default to HEAD when <branch> is omittedLibravatar Eric Sunshine3-2/+10
As a convenience, like "git branch" and "git checkout -b", make "git worktree add -b <newbranch> <path> <branch>" default to HEAD when <branch> is omitted. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: extract basename computation to new functionLibravatar Eric Sunshine1-9/+20
A subsequent patch will also need to compute the basename of the new worktree, so factor out this logic into a new function. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: require worktree unconditionallyLibravatar Eric Sunshine2-3/+1
In order to allow linked worktree creation via "git checkout --to" from a bare repository, 3473ad0 (checkout: don't require a work tree when checking out into a new one, 2014-11-30) dropped git-checkout's unconditional NEED_WORK_TREE requirement and instead performed worktree setup conditionally based upon presence or absence of the --to option. Now that --to has been retired and git-checkout is no longer responsible for linked worktree creation, the NEED_WORK_TREE requirement can be re-instated. This effectively reverts 3473ad0, except for the tests it added which now check bare repository behavior of "git worktree add" instead. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: retire --to optionLibravatar Eric Sunshine3-173/+139
Now that "git worktree add" has achieved user-facing feature-parity with "git checkout --to", retire the latter. Move the actual linked worktree creation functionality, prepare_linked_checkout() and its helpers, verbatim from checkout.c to worktree.c. This effectively reverts changes to checkout.c by 529fef2 (checkout: support checking out into a new working directory, 2014-11-30) with the exception of merge_working_tree() and switch_branches() which still require specialized knowledge that a the checkout is occurring in a newly-created linked worktree (signaled to them by the private GIT_CHECKOUT_NEW_WORKTREE environment variable). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06tests: worktree: retrofit "checkout --to" tests for "worktree add"Libravatar Eric Sunshine3-29/+25
With the introduction of "git worktree add", "git checkout --to" is slated for removal. Therefore, retrofit linked worktree creation tests to use "git worktree add" instead. (The test to check exclusivity of "checkout --to" and "checkout <paths>" is dropped altogether since it becomes meaningless with retirement of "checkout --to".) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: add -b/-B optionsLibravatar Eric Sunshine2-3/+21
One of git-worktree's roles is to populate the new worktree, much like git-checkout, and thus, for convenience, ought to support several of the same shortcuts. Toward this goal, add -b/-B options to create a new branch and check it out in the new worktree. (For brevity, only -b is mentioned in the synopsis; -B is omitted.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: add --detach optionLibravatar Eric Sunshine2-2/+9
One of git-worktree's roles is to populate the new worktree, much like git-checkout, and thus, for convenience, ought to support several of the same shortcuts. Toward this goal, add a --detach option to detach HEAD in the new worktree. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: add --force optionLibravatar Eric Sunshine2-2/+12
By default, "git worktree add" refuses to create a new worktree when the requested branch is already checked out elsewhere. Add a --force option to override this safeguard. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06worktree: introduce "add" commandLibravatar Eric Sunshine2-10/+41
The plan is to relocate "git checkout --to" functionality to "git worktree add". As a first step, introduce a bare-bones git-worktree "add" command along with documentation. At this stage, "git worktree add" merely invokes "git checkout --to" behind the scenes, but an upcoming patch will move the actual functionality (checkout.c:prepare_linked_checkout() and its helpers) to worktree.c. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: drop 'checkout_opts' dependency from prepare_linked_checkoutLibravatar Eric Sunshine1-4/+5
The plan is to relocate "git checkout --to" functionality to "git worktree add", however, worktree.c won't have access to the 'struct checkout_opts' passed to prepare_linked_worktree(), which it consults for the pathname of the new worktree and the argv[] of the command it should run to populate the new worktree. Facilitate relocation of prepare_linked_worktree() by instead having it accept the pathname and argv[] directly, thus eliminating the final references to 'struct checkout_opts'. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: make --to unconditionally verboseLibravatar Eric Sunshine1-2/+1
prepare_linked_checkout() respects git-checkout's --quiet flag, however, the plan is to relocate "git checkout --to" functionality to "git worktree add", and git-worktree does not (yet) have a --quiet flag. Consequently, make prepare_linked_checkout() unconditionally verbose to ease eventual code movement to worktree.c. (A --quiet flag can be added to git-worktree later if there is demand for it.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: prepare_linked_checkout: drop now-unused 'new' argumentLibravatar Eric Sunshine1-3/+2
The only references to 'new' were folded out by the last two patches. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: relocate --to's "no branch specified" checkLibravatar Eric Sunshine1-3/+4
The plan is to relocate "git checkout --to" functionality to "git worktree add", however, this check expects a 'struct branch_info' which git-worktree won't have at hand. It will, however, have access to its own command-line from which it can pick up the branch name. Therefore, as a preparatory step, rather than having prepare_linked_checkout() perform this check, make it the caller's responsibility. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06checkout: fix bug with --to and relative HEADLibravatar Eric Sunshine2-4/+22
Given "git checkout --to <path> HEAD~1", the new worktree's HEAD should begin life at the current branch's HEAD~1, however, it actually ends up at HEAD~2. This happens because: 1. git-checkout resolves HEAD~1 2. to satisfy is_git_directory(), prepare_linked_worktree() creates a HEAD for the new worktree with the value of the resolved HEAD~1 3. git-checkout re-invokes itself with the same arguments within the new worktree to populate the worktree 4. the sub git-checkout resolves HEAD~1 relative to its own HEAD, which is the resolved HEAD~1 from the original invocation, resulting unexpectedly and incorrectly in HEAD~2 (relative to the original) Fix this by unconditionally assigning the current worktree's HEAD as the value of the new worktree's HEAD. As a side-effect, this change also eliminates a dependence within prepare_linked_checkout() upon 'struct branch_info'. The plan is to eventually relocate "git checkout --to" functionality to "git worktree add", and worktree.c won't have knowledge of 'struct branch_info', so removal of this dependency is a step toward that goal. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/git-worktree: add EXAMPLES sectionLibravatar Eric Sunshine1-0/+22
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/git-worktree: add high-level 'lock' overviewLibravatar Eric Sunshine1-9/+15
Due to the (current) absence of a "git worktree lock" command, locking a worktree's administrative files to prevent automatic pruning is a manual task, necessarily requiring low-level understanding of linked worktree functionality. However, this level of detail does not belong in the high-level DESCRIPTION section, so add a generalized discussion of locking to DESCRIPTION and move the technical information to DETAILS. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/git-worktree: split technical info from general descriptionLibravatar Eric Sunshine1-34/+36
The DESCRIPTION section should provide a high-level overview of linked worktree functionality to bring users up to speed quickly, without overloading them with low-level details, so relocate the technical information to a new DETAILS section. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/git-worktree: add BUGS sectionLibravatar Eric Sunshine1-3/+16
Relocate submodule warning to BUGS and enumerate missing commands. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>