summaryrefslogtreecommitdiff
path: root/Documentation/git-checkout.txt
AgeCommit message (Collapse)AuthorFilesLines
2019-05-19Merge branch 'dl/branch-from-3dot-merge-base'Libravatar Junio C Hamano1-0/+4
"git branch new A...B" and "git checkout -b new A...B" have been taught that in their contexts, the notation A...B means "the merge base between these two commits", just like "git checkout A...B" detaches HEAD at that commit. * dl/branch-from-3dot-merge-base: branch: make create_branch accept a merge base rev t2018: cleanup in current test
2019-05-07branch: make create_branch accept a merge base revLibravatar Denton Liu1-0/+4
When we ran something like $ git checkout -b test master... it would fail with the message fatal: Not a valid object name: 'master...'. This was caused by the call to `create_branch` where `start_name` is expected to be a valid rev. However, git-checkout allows the branch to be a valid _merge base_ rev (i.e. with a "...") so it was possible for an invalid rev to be passed in. Make `create_branch` accept a merge base rev so that this case does not error out. As a side-effect, teach git-branch how to handle merge base revs as well. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16Merge branch 'nd/checkout-m-doc-update'Libravatar Junio C Hamano1-0/+2
Doc about the above. * nd/checkout-m-doc-update: checkout.txt: note about losing staged changes with --merge
2019-03-21checkout.txt: note about losing staged changes with --mergeLibravatar Nguyễn Thái Ngọc Duy1-0/+2
If you have staged changes in path A and perform 'checkout --merge' (which could result in conflicts in a totally unrelated path B), changes in A will be gone. Which is unexpected. We are supposed to keep all changes, or kick and scream otherwise. This is the result of how --merge is implemented, from the very first day in 1be0659efc (checkout: merge local modifications while switching branches., 2006-01-12): 1. a merge is done, unmerged entries are collected 2. a hard switch to a new branch is done, then unmerged entries added back There is no trivial fix for this. Going with 3-way merge one file at a time loses rename detection. Going with 3-way merge by trees requires teaching the algorithm to pick up staged changes. And even if we detect staged changes with --merge and abort for safety, an option to continue --merge is very weird. Such an option would keep worktree changes, but drop staged changes. Because the problem has been with us since the introduction of --merge and everybody has been pretty happy (except Phillip, who found this problem), I'll just take a note here to acknowledge it and wait for merge wizards to come in and work their magic. There may be a way forward [1]. [1] CABPp-BFoL_U=bzON4SEMaQSKU2TKwnOgNqjt5MUaOejTKGUJxw@mail.gmail.com Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'tg/checkout-no-overlay'Libravatar Junio C Hamano1-0/+10
"git checkout --no-overlay" can be used to trigger a new mode of checking out paths out of the tree-ish, that allows paths that match the pathspec that are in the current index and working tree and are not in the tree-ish. * tg/checkout-no-overlay: revert "checkout: introduce checkout.overlayMode config" checkout: introduce checkout.overlayMode config checkout: introduce --{,no-}overlay option checkout: factor out mark_cache_entry_for_checkout function checkout: clarify comment read-cache: add invalidate parameter to remove_marked_cache_entries entry: support CE_WT_REMOVE flag in checkout_entry entry: factor out unlink_entry function move worktree tests to t24*
2019-02-24Merge branch 'yn/checkout-doc-fix'Libravatar Junio C Hamano1-1/+1
Doc fix. * yn/checkout-doc-fix: checkout doc: fix an unmatched double-quote pair
2019-02-23checkout doc: fix an unmatched double-quote pairLibravatar Yoichi Nakayama1-1/+1
Signed-off-by: Yoichi Nakayama <yoichi.nakayama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'ja/doc-style-fix'Libravatar Junio C Hamano1-8/+8
Doc typo/stylo fixes. * ja/doc-style-fix: doc: tidy asciidoc style
2019-01-23doc: tidy asciidoc styleLibravatar Jean-Noël Avila1-8/+8
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08checkout: introduce --{,no-}overlay optionLibravatar Thomas Gummerer1-0/+10
Currently 'git checkout' is defined as an overlay operation, which means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an entry in the index that matches <pathspec>, but that doesn't exist in <tree-ish>, that entry will not be removed from the index or the working tree. Introduce a new --{,no-}overlay option, which allows using 'git checkout' in non-overlay mode, thus removing files from the working tree if they do not exist in <tree-ish> but match <pathspec>. Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works this way, so no changes are needed for the patch mode. We disallow 'git checkout --overlay -p' to avoid confusing users who would expect to be able to force overlay mode in 'git checkout -p' this way. Untracked files are not affected by this change, so 'git checkout --no-overlay HEAD -- untracked' will not remove untracked from the working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/' doesn't delete all untracked files in dir/, but rather just resets the state of files that are known to git. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14checkout: disambiguate dwim tracking branches and local filesLibravatar Nguyễn Thái Ngọc Duy1-0/+4
When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] 70c9ac2f19 (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] a047fafc78 (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23doc: fix ASCII art tab spacingLibravatar Andreas Heiduk1-7/+7
Followup to 5dd05ebf ("doc: fix merge-base ASCII art tab spacing", 2016-10-21) Signed-off-by: Andreas Heiduk <asheiduk@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>
2017-12-13Merge branch 'ks/doc-checkout-previous'Libravatar Junio C Hamano1-4/+4
@{-N} in "git checkout @{-N}" may refer to a detached HEAD state, but the documentation was not clear about it, which has been fixed. * ks/doc-checkout-previous: Doc/checkout: checking out using @{-N} can lead to detached state
2017-12-06Merge branch 'sb/submodule-recursive-checkout-detach-head'Libravatar Junio C Hamano1-0/+2
"git checkout --recursive" may overwrite and rewind the history of the branch that happens to be checked out in submodule repositories, which might not be desirable. Detach the HEAD but still allow the recursive checkout to succeed in such a case. * sb/submodule-recursive-checkout-detach-head: Documentation/checkout: clarify submodule HEADs to be detached recursive submodules: detach HEAD from new state
2017-11-28Doc/checkout: checking out using @{-N} can lead to detached stateLibravatar Kaartic Sivaraam1-4/+4
@{-N} is a syntax for the N-th last "checkout" and not the N-th last "branch". Therefore, in some cases using `git checkout @{-$N}` DOES lead to a "detached HEAD" state. This can also be ensured by the commit message of 75d6e552a (Documentation: @{-N} can refer to a commit, 2014-01-19) which clearly specifies how @{-N} can be used to refer not only to a branch but also to a commit. Correct the misleading sentence which states that @{-N} doesn't detach HEAD. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-17Merge branch 'jc/doc-checkout'Libravatar Junio C Hamano1-14/+16
Doc update. * jc/doc-checkout: checkout doc: clarify command line args for "checkout paths" mode
2017-10-11checkout doc: clarify command line args for "checkout paths" modeLibravatar Junio C Hamano1-14/+16
There are "git checkout [-p][<tree-ish>][--][<paths>...]" in the SYNOPSIS section, and "git checkout [-p][<tree-ish>][--]<paths>..." as the header for the section that explains the "check out paths from index/tree-ish" mode. It is unclear if we require at least one path, or it is entirely optional. Actually, both are wrong. Without the "-p(atch)" option, you must have <pathspec> (otherwise, with a commit that is a <tree-ish>, you would be checking out that commit to build a new history on top of it). With it, it is already clear that you are checking out paths, it is optional. In other words, you cannot omit both. The source of the confusion is that -p(atch) is described as if it is just another "optional" part and its description is lumped together with the non patch mode, even though the actual end user experience is vastly different. Let's split the entry into two, and describe the regular mode and the patch mode separately. This allows us to make it clear that the regular mode MUST be given at least one pathspec, that the patch mode can be invoked with either '-p' or '--patch' but one of these must be given, and that the pathspec is entirely optional in the patch mode. Also, revamp the explanation of "checkout paths" by removing extraneous description at the beginning, that says "checking out paths is not checking out a branch". Explaining what it is for and when the user wants to use it upfront is the most direct way to help the readers. Noticed-by: Robert P J Day Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-14doc: fix minor typos (extra/duplicated words)Libravatar Evan Zacks1-1/+1
Following are several fixes for duplicated words ("of of") and one case where an extra article ("a") slipped in. Signed-off-by: Evan Zacks <zackse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28Documentation/checkout: clarify submodule HEADs to be detachedLibravatar Stefan Beller1-0/+2
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16builtin/checkout: add --recurse-submodules switchLibravatar Stefan Beller1-0/+7
This exposes a flag to recurse into submodules in builtin/checkout making use of the code implemented in prior patches. A new failure mode is introduced in the submodule update library, as the directory/submodule conflict is not solved in prior patches. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21checkout.txt: document a common case that ignores ambiguation rulesLibravatar Nguyễn Thái Ngọc Duy1-0/+12
Normally we err on the safe side: if something can be seen as both an SHA1 and a pathspec, we stop and scream. In checkout, there is one exception added in 859fdab (git-checkout: improve error messages, detect ambiguities. - 2008-07-23), to allow the common case "git checkout branch". Let's document this exception. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset short command-line options as literalLibravatar Matthieu Moy1-2/+2
It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01checkout: add --progress optionLibravatar Edmundo Carmona Antoranz1-0/+6
Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona Antoranz <eantoranz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'se/doc-checkout-ours-theirs'Libravatar Junio C Hamano1-0/+15
A "rebase" replays changes of the local branch on top of something else, as such they are placed in stage #3 and referred to as "theirs", while the changes in the new base, typically a foreign work, are placed in stage #2 and referred to as "ours". Clarify the "checkout --ours/--theirs". * se/doc-checkout-ours-theirs: checkout: document subtlety around --ours/--theirs
2015-07-13Merge branch 'es/worktree-add'Libravatar Junio C Hamano1-72/+0
Update to the "linked checkout" in 2.5.0-rc1. Instead of "checkout --to" that does not do what "checkout" normally does, move the functionality to "git worktree add". * es/worktree-add: (24 commits) Revert "checkout: retire --ignore-other-worktrees in favor of --force" checkout: retire --ignore-other-worktrees in favor of --force worktree: add: auto-vivify new branch when <branch> is omitted worktree: add: make -b/-B default to HEAD when <branch> is omitted worktree: extract basename computation to new function checkout: require worktree unconditionally checkout: retire --to option tests: worktree: retrofit "checkout --to" tests for "worktree add" worktree: add -b/-B options worktree: add --detach option worktree: add --force option worktree: introduce "add" command checkout: drop 'checkout_opts' dependency from prepare_linked_checkout checkout: make --to unconditionally verbose checkout: prepare_linked_checkout: drop now-unused 'new' argument checkout: relocate --to's "no branch specified" check checkout: fix bug with --to and relative HEAD Documentation/git-worktree: add EXAMPLES section Documentation/git-worktree: add high-level 'lock' overview Documentation/git-worktree: split technical info from general description ...
2015-07-12Revert "checkout: retire --ignore-other-worktrees in favor of --force"Libravatar Junio C Hamano1-3/+6
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-12checkout: document subtlety around --ours/--theirsLibravatar Simon A. Eugster1-0/+15
During a 'rebase' (hence 'pull --rebase'), --ours/--theirs may appear to be swapped to those who are not aware of the fact that they are temporarily playing the role of the keeper of the more authoritative history. Add a note to clarify. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Simon A. Eugster <simon.eugster@eps.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-10Merge branch 'tb/checkout-doc'Libravatar Junio C Hamano1-1/+5
Doc update. * tb/checkout-doc: git-checkout.txt: document "git checkout <pathspec>" better
2015-07-07checkout: retire --ignore-other-worktrees in favor of --forceLibravatar Eric Sunshine1-6/+3
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-06checkout: retire --to optionLibravatar Eric Sunshine1-7/+0
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-06Documentation: move linked worktree description from checkout to worktreeLibravatar Eric Sunshine1-67/+2
Now that the git-worktree command exists, its documentation page is the natural place for the linked worktree description to reside. Relocate the "MULTIPLE WORKING TREES" description verbatim from git-checkout.txt to git-worktree.txt. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/git-checkout: fix incorrect worktree prune commandLibravatar Eric Sunshine1-1/+1
This was missed when "git prune --worktrees" became "git worktree prune". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-17git-checkout.txt: document "git checkout <pathspec>" betterLibravatar Torsten Bögershausen1-1/+5
git checkout <pathspec> can be used to reset changes in the working tree. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Merge branch 'nd/multiple-work-trees'Libravatar Junio C Hamano1-0/+78
A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. * nd/multiple-work-trees: (41 commits) prune --worktrees: fix expire vs worktree existence condition t1501: fix test with split index t2026: fix broken &&-chain t2026 needs procondition SANITY git-checkout.txt: a note about multiple checkout support for submodules checkout: add --ignore-other-wortrees checkout: pass whole struct to parse_branchname_arg instead of individual flags git-common-dir: make "modules/" per-working-directory directory checkout: do not fail if target is an empty directory t2025: add a test to make sure grafts is working from a linked checkout checkout: don't require a work tree when checking out into a new one git_path(): keep "info/sparse-checkout" per work-tree count-objects: report unused files in $GIT_DIR/worktrees/... gc: support prune --worktrees gc: factor out gc.pruneexpire parsing code gc: style change -- no SP before closing parenthesis checkout: clean up half-prepared directories in --to mode checkout: reject if the branch is already checked out elsewhere prune: strategies for linked checkouts checkout: support checking out into a new working directory ...
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07git-checkout.txt: a note about multiple checkout support for submodulesLibravatar Nguyễn Thái Ngọc Duy1-0/+3
The goal seems to be using multiple checkouts to reduce disk space. But we have not reached an agreement how things should be. There are a couple options. - You may want to keep $SUB repos elsewhere (perhaps in a central place) outside $SUPER. This is also true for nested submodules where a superproject may be a submodule of another superproject. - You may want to keep all $SUB repos in $SUPER/modules (or some other place in $SUPER) - We could even push it further and merge all $SUB repos into $SUPER instead of storing them separately. But that would at least require ref namespace enabled. On top of that, git-submodule.sh expects $GIT_DIR/config to be per-worktree, at least for the submodule.* part. Here I think we have two options, either update config.c to also read $GIT_DIR/config.worktree (which is per worktree) in addition to $GIT_DIR/config (shared) and store worktree-specific vars in the new place, or update git-submodule.sh to read/write submodule.* directly from $GIT_DIR/config.submodule (per worktree). These take time to address properly. Meanwhile, make a note to the user that they should not use multiple worktrees in submodule context. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07checkout: add --ignore-other-wortreesLibravatar Nguyễn Thái Ngọc Duy1-0/+6
Noticed-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01gc: support prune --worktreesLibravatar Nguyễn Thái Ngọc Duy1-4/+7
Helped-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01prune: strategies for linked checkoutsLibravatar Nguyễn Thái Ngọc Duy1-0/+20
(alias R=$GIT_COMMON_DIR/worktrees/<id>) - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. - linked checkouts are supposed to update mtime of $R/gitdir. If $R/gitdir's mtime is older than a limit, and it points to nowhere, worktrees/<id> is to be pruned. - If $R/locked exists, worktrees/<id> is not supposed to be pruned. If $R/locked exists and $R/gitdir's mtime is older than a really long limit, warn about old unused repo. - "git checkout --to" is supposed to make a hard link named $R/link pointing to the .git file on supported file systems to help detect the user manually deleting the checkout. If $R/link exists and its link count is greated than 1, the repo is kept. Helped-by: Marc Branchaud <marcnarc@xiplink.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01checkout: support checking out into a new working directoryLibravatar Nguyễn Thái Ngọc Duy1-0/+46
"git checkout --to" sets up a new working directory with a .git file pointing to $GIT_DIR/worktrees/<id>. It then executes "git checkout" again on the new worktree with the same arguments except "--to" is taken out. The second checkout execution, which is not contaminated with any info from the current repository, will actually check out and everything that normal "git checkout" does. Helped-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-21Documentation: @{-N} can refer to a commitLibravatar Thomas Rast1-2/+2
The @{-N} syntax always referred to the N-th last thing checked out, which can be either a branch or a commit (for detached HEAD cases). However, the documentation only mentioned branches. Edit in a "/commit" in the appropriate places. Reported-by: Kevin <ikke@ikke.info> Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11checkout: update synopsys and documentation on detaching HEADLibravatar Junio C Hamano1-6/+8
In the synopsis, the second form to detach HEAD at the named commit labelled the argument as '<commit>'. While this is technically more correct, because the feature to detach is not limited to the tip of a named branch, it was found confusing and did not express the fact that you have to give `--detach` if you are naming the commit you want to detach HEAD at with a branch name. Separate this case into two syntactical forms, mimicking the way how the DESCRIPTION section shows this usage. Also update the text that explains the syntax to name the commit to detach HEAD at to clarify. Suggested-by: Benjamin Bergman <ben@benbergman.ca> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano1-3/+3
Update "git checkout foo" that DWIMs the intended "upstream" and turns it into "git checkout -t -b foo remotes/origin/foo" to correctly take existing remote definitions into account. The remote "origin" may be what uniquely map its own branch to remotes/some/where/foo but that some/where may not be "origin". * jh/checkout-auto-tracking: glossary: Update and rephrase the definition of a remote-tracking branch branch.c: Validate tracking branches with refspecs instead of refs/remotes/* t9114.2: Don't use --track option against "svn-remote"-tracking branches t7201.24: Add refspec to keep --track working t3200.39: tracking setup should fail if there is no matching refspec. checkout: Use remote refspecs when DWIMming tracking branches t2024: Show failure to use refspec when DWIMming remote branch names t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
2013-04-21checkout: Use remote refspecs when DWIMming tracking branchesLibravatar Johan Herland1-3/+3
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15checkout: add --ignore-skip-worktree-bits in sparse checkout modeLibravatar Nguyễn Thái Ngọc Duy1-0/+6
"git checkout -- <paths>" is usually used to restore all modified files in <paths>. In sparse checkout mode, this command is overloaded with another meaning: to add back all files in <paths> that are excluded by sparse patterns. As the former makes more sense for day-to-day use. Switch it to the default and the latter enabled with --ignore-skip-worktree-bits. While at there, add info/sparse-checkout to gitrepository-layout.txt Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-2/+2
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-18Documentation/git-checkout.txt: document 70c9ac2 behaviorLibravatar Chris Rorvick1-0/+8
Document the behavior implemented in 70c9ac2 (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"). Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-18Documentation/git-checkout.txt: clarify usageLibravatar Chris Rorvick1-10/+33
The forms of checkout that do not take a path are lumped together in the DESCRIPTION section, but the description for this group is dominated by explanation of the -b|-B form. Split these apart for more clarity. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-12Merge branch 'jc/maint-checkout-fileglob-doc'Libravatar Junio C Hamano1-0/+12
Updated with help from Peff. * jc/maint-checkout-fileglob-doc: gitcli: contrast wildcard given to shell and to git gitcli: formatting fix Document file-glob for "git checkout -- '*.c'"