path: root/Documentation/git-checkout.txt
AgeCommit message (Collapse)Author
2009-09-07Merge branch 'tr/reset-checkout-patch'Junio C Hamano
* tr/reset-checkout-patch: stash: simplify defaulting to "save" and reject unknown options Make test case number unique tests: disable interactive hunk selection tests if perl is not available DWIM 'git stash save -p' for 'git stash -p' Implement 'git stash save --patch' Implement 'git checkout --patch' Implement 'git reset --patch' builtin-add: refactor the meat of interactive_add() Add a small patch-mode testing library git-apply--interactive: Refactor patch mode code Make 'git stash -k' a short form for 'git stash save --keep-index'
2009-08-29UI consistency: allow --force for where -f means forceRené Scharfe
git branch, checkout, clean, mv and tag all have an option -f to override certain checks. This patch makes them accept the long option --force as a synonym. While we're at it, document that checkout support --quiet as synonym for its short option -q. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2009-08-15Implement 'git checkout --patch'Thomas Rast
This introduces a --patch mode for git-checkout. In the index usage git checkout --patch -- [files...] it lets the user discard edits from the <files> at the granularity of hunks (by selecting hunks from 'git diff' and then reverse applying them to the worktree). We also accept a revision argument. In the case git checkout --patch HEAD -- [files...] we offer hunks from the difference between HEAD and the worktree, and reverse applies them to both index and worktree, allowing you to discard staged changes completely. In the non-HEAD usage git checkout --patch <revision> -- [files...] it offers hunks from the difference between the worktree and <revision>. The chosen hunks are then applied to both index and worktree. The application to worktree and index is done "atomically" in the sense that we first check if the patch applies to the index (it should always apply to the worktree). If it does not, we give the user a choice to either abort or apply to the worktree anyway. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2009-04-13docs/checkout: clarify what "non-branch" meansJeff King
In the code we literally stick "refs/heads/" on the front and see if it resolves, so that is probably the best explanation. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-04-13doc/checkout: split checkout and branch creation in synopsisJeff King
These can really be thought of as two different modes, since the "<branch>" parameter is treated differently in the two (in one it is the branch to be checked out, but in the other it is really a start-point for branch creation). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-04-13doc/checkout: refer to git-branch(1) as appropriateJeff King
Most of description for the branch creation options is simply cut and paste from git-branch. There are two reasons to fix this: 1. It can grow stale with respect to what's in "git branch" (which it is now is). 2. It is not just an implementation detail, but rather the desired mental model for the command that we are using "git branch" here. Being explicit about that can help the user understand what is going on. It also makes sense to strip the branch creation options from the synopsis, as they are making it a long, hard-to-read line. They are still easily discovered by reading the options list, and --track is explicitly referenced when branch creation is described. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-04-13doc: refer to tracking configuration as "upstream"Jeff King
The term "tracking" often creates confusion between remote tracking branches and local branches which track a remote branch. The term "upstream" captures more clearly the idea of "branch A is based on branch B in some way", so it makes sense to mention it. At the same time, upstream branches are used for more than just git-pull these days; let's mention that here. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-04-13doc: clarify --no-track optionJeff King
It is not really about ignoring the config option; it is about turning off tracking, _even if_ the config option is set. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-04-08Merge branch 'maint'Junio C Hamano
* maint: Change double quotes to single quotes in message Documentation: clarify .gitattributes search git-checkout.txt: clarify that <branch> applies when no path is given. git-checkout.txt: fix incorrect statement about HEAD and index Conflicts: Documentation/git-checkout.txt
2009-04-08Merge branch 'maint-1.6.1' into maintJunio C Hamano
* maint-1.6.1: Documentation: clarify .gitattributes search git-checkout.txt: clarify that <branch> applies when no path is given. git-checkout.txt: fix incorrect statement about HEAD and index
2009-04-08Merge branch 'maint-1.6.0' into maint-1.6.1Junio C Hamano
* maint-1.6.0: Documentation: clarify .gitattributes search git-checkout.txt: clarify that <branch> applies when no path is given. git-checkout.txt: fix incorrect statement about HEAD and index
2009-04-08git-checkout.txt: clarify that <branch> applies when no path is given.Matthieu Moy
Otherwise, the sentence "Defaults to HEAD." can be mis-read to mean that "git checkout -- hello.c" checks-out from HEAD. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-04-08git-checkout.txt: fix incorrect statement about HEAD and indexMatthieu Moy
The command "git checkout" checks out from the index by default, not HEAD (the introducing comment were correct, but the detailled explanation added below were not). Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-03-17Documentation: remove extra quoting/emphasis around literal textsChris Johnsen
If literal text (asciidoc `...`) can be rendered in a differently from normal text for each output format (man, HTML), then we do not need extra quotes or other wrapping around inline literal text segments. config.txt Change '`...`' to `...`. In asciidoc, the single quotes provide emphasis, literal text should be distintive enough. Change "`...`" to `...`. These double quotes do not work if present in the described config value, so drop them. git-checkout.txt Change "`...`" to `...` or `"..."`. All instances are command line argument examples. One "`-`" becomes `-`. Two others are involve curly braces, so move the double quotes inside the literal region to indicate that they might need to be quoted on the command line of certain shells (tcsh). git-merge.txt Change "`...`" to `...`. All instances are used to describe merge conflict markers. The quotes should are not important. git-rev-parse.txt Change "`...`" to `...`. All instances are around command line arguments where no in-shell quoting should be necessary. gitcli.txt Change `"..."` to `...`. All instances are around command line examples or single command arguments. They do not semanticly belong inside the literal text, and they are not needed outside it. glossary-content.txt user-manual.txt Change "`...`" to `...`. All instances were around command lines. Signed-off-by: Chris Johnsen <> Signed-off-by: Junio C Hamano <>
2009-03-11Typo and language fixes for git-checkout.txtMichael J Gruber
Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2009-01-18checkout: implement "-" abbreviation, add docs and testsThomas Rast
Have '-' mean the same as '@{-1}', i.e., the last branch we were on. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2008-12-19Documentation: sync example output with git outputMarkus Heidelberg
Don't confuse the user with old git messages. Signed-off-by: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2008-12-18Clarify documentation of "git checkout <tree-ish> paths" syntaxNanako Shiraishi
The SYNOPSIS section of the manual writes: git checkout [options] [<tree-ish>] [--] <paths>... but the DESCRIPTION says that this form checks the paths out "from the index, or from a named commit." A later sentence refers to the same argument as "<tree-ish> argument", but it is not clear that these two sentences are talking about the same command line argument for first-time readers. Signed-off-by: Nanako Shiraishi <> Signed-off-by: Junio C Hamano <>
2008-10-19Documentation: Spelling fixFredrik Skolmli
Signed-off-by: Fredrik Skolmli <> Signed-off-by: Junio C Hamano <>
2008-09-29Merge branch 'jc/better-conflict-resolution'Shawn O. Pearce
* jc/better-conflict-resolution: Fix AsciiDoc errors in merge documentation git-merge documentation: describe how conflict is presented checkout --conflict=<style>: recreate merge in a non-default style checkout -m: recreate merge when checking out of unmerged index git-merge-recursive: learn to honor merge.conflictstyle merge.conflictstyle: choose between "merge" and "diff3 -m" styles rerere: understand "diff3 -m" style conflicts with the original rerere.c: use symbolic constants to keep track of parsing states xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less xmerge.c: minimum readability fixups xdiff-merge: optionally show conflicts in "diff3 -m" style xdl_fill_merge_buffer(): separate out a too deeply nested function checkout --ours/--theirs: allow checking out one side of a conflicting merge checkout -f: allow ignoring unmerged paths when checking out of the index Conflicts: Documentation/git-checkout.txt builtin-checkout.c builtin-merge-recursive.c t/
2008-09-01checkout --conflict=<style>: recreate merge in a non-default styleJunio C Hamano
This new option does essentially the same thing as -m option when checking unmerged paths out of the index, but it uses the specified style instead of configured merge.conflictstyle. Setting "merge.conflictstyle" to "diff3" is usually less useful than using the default "merge" style, because the latter allows a conflict that results by both sides changing the same region in a very similar way to get simplified substancially by reducing the common lines. However, when one side removed a group of lines (perhaps a function was moved to some other file) while the other side modified it, the default "merge" style does not give any clue as to why the hunk is left conflicting. You would need the original to understand what is going on. The recommended use would be not to set merge.conflictstyle variable so that you would usually use the default "merge" style conflict, and when the result in a path in a particular merge is too hard to understand, use "git checkout --conflict=diff3 $path" to check it out with the original to review what is going on. Signed-off-by: Junio C Hamano <>
2008-08-31checkout -m: recreate merge when checking out of unmerged indexJunio C Hamano
This teaches git-checkout to recreate a merge out of unmerged index entries while resolving conflicts. With this patch, checking out an unmerged path from the index now have the following possibilities: * Without any option, an attempt to checkout an unmerged path will atomically fail (i.e. no other cleanly-merged paths are checked out either); * With "-f", other cleanly-merged paths are checked out, and unmerged paths are ignored; * With "--ours" or "--theirs, the contents from the specified stage is checked out; * With "-m" (we should add "--merge" as synonym), the 3-way merge is recreated from the staged object names and checked out. Signed-off-by: Junio C Hamano <>
2008-08-31checkout --ours/--theirs: allow checking out one side of a conflicting mergeJunio C Hamano
This lets you to check out 'our' (or 'their') version of an unmerged path out of the index while resolving conflicts. Signed-off-by: Junio C Hamano <>
2008-08-31checkout -f: allow ignoring unmerged paths when checking out of the indexJunio C Hamano
Earlier we made "git checkout $pathspec" to atomically refuse the operation of $pathspec matched any path with unmerged stages. This patch allows: $ git checkout -f a b c to ignore, instead of error out on, such unmerged paths. The fix to prevent checkout of an unmerged path from random stages is still there. Signed-off-by: Junio C Hamano <>
2008-08-23Extend "checkout --track" DWIM to support more casesAlex Riesen
The code handles additionally "refs/remotes/<something>/name", "remotes/<something>/name", and "refs/<namespace>/name". Signed-off-by: Alex Riesen <> Signed-off-by: Junio C Hamano <>
2008-08-11checkout --track: make up a sensible branch name if '-b' was omittedJohannes Schindelin
What does the user most likely want with this command? $ git checkout --track origin/next Exactly. A branch called 'next', that tracks origin's branch 'next'. Make it so. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2008-07-25checkout: mention '--' in the docsSZEDER Gábor
'git checkout' uses '--' to separate options from paths, but it was not mentioned in the documentation Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2008-07-05manpages: italicize git command names (which were in teletype font)Jonathan Nieder
The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }' } for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \ merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation formatting and cleanupJonathan Nieder
Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-07-02Documentation: be consistent about "git-" versus "git "Jonathan Nieder
Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2008-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsStephan Beyer
The OPTIONS section of a documentation file contains a list of the options a git command accepts. Currently there are several variants to describe the case that different options (almost) do the same in the OPTIONS section. Some are: -f, --foo:: -f|--foo:: -f | --foo:: But AsciiDoc has the special form: -f:: --foo:: This patch applies this form to the documentation of the whole git suite, and removes useless em-dash prevention, so \--foo becomes --foo. Signed-off-by: Stephan Beyer <> Signed-off-by: Junio C Hamano <>
2008-06-06documentation: move git(7) to git(1)Christian Couder
As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2008-04-27git checkout: add -t alias for --trackMiklos Vajna
Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2008-03-25Documentation/git-checkout: Update summary to reflect current abilitiesJulian Phillips
For a while now, git-checkout has been more powerful than the man-page summary would suggest (the main text does describe the new features), so update the summary to hopefully better reflect the current functionality. Also update the glossary description of the word checkout. Signed-off-by: Julian Phillips <> Signed-off-by: Junio C Hamano <>
2008-02-20doc: documentation update for the branch track changesJay Soffian
Documents the branch.autosetupmerge=always setting and usage of --track when branching from a local branch. Signed-off-by: Jay Soffian <> Signed-off-by: Junio C Hamano <>
2008-01-07Documentation: rename gitlink macro to linkgitDan McGee
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <> Signed-off-by: Junio C Hamano <>
2007-10-03Say when --track is useful in the git-checkout docs.Federico Mena Quintero
The documentation used to say what the option does, but it didn't mention a use case. Signed-off-by: Federico Mena Quintero <> Signed-off-by: Junio C Hamano <>
2007-08-20Fix misspelling of 'suppress' in docsDave Watson
Signed-off-by: Junio C Hamano <>
2007-07-11branch --track: code cleanup and saner handling of local branchesJohannes Schindelin
This patch cleans up some complicated code, and replaces it with a cleaner version, using code from remote.[ch], which got extended a little in the process. This also enables us to fix two cases: The earlier "fix" to setup tracking only when the original ref started with "refs/remotes" is wrong. You are absolutely allowed to use a separate layout for your tracking branches. The correct fix, of course, is to set up tracking information only when there is a matching remote.<nick>.fetch line containing a colon. Another corner case was not handled properly. If two remotes write to the original ref, just warn the user and do not set up tracking. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2007-07-09branch.autosetupmerge: allow boolean values, or "all"Johannes Schindelin
Junio noticed that switching on autosetupmerge unilaterally started cluttering the config for local branches. That is not the original intention of branch.autosetupmerge, which was meant purely for convenience when branching off of remote branches, but that semantics got lost somewhere. If you still want that "new" behavior, you can switch branch.autosetupmerge to the value "all". Otherwise, it is interpreted as a boolean, which triggers setting up defaults _only_ when branching off of a remote branch, i.e. the originally intended behavior. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2007-07-02Documentation: minor cleanups to branch/checkout wordingJeff King
Change "to made" to "made to", which is a typo. Use "reflog" instead of "ref log", which is used elsewhere throughout the documentation. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2007-07-02Documentation: quote {non-attributes} for asciidocJeff King
Asciidoc treats {foo} as an attribute to be substituted; if 'foo' doesn't exist as an attribute, then the entire line gets dropped. When the literal {foo} is desired, \{foo} is required. The exceptions to this rule are: - inside literal blocks - if the 'foo' contains non-alphanumeric characters (e.g., {foo|bar} is assumed not to be an attribute) Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2007-06-07War on whitespaceJunio C Hamano
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <>
2007-04-23Reverse the order of -b and --track in the man page.Brian Gernhardt
Using "-b --track newbranch oldbranch" gives the error: git checkout: updating paths is incompatible with switching branches/forcing However, "--track -b ..." works just fine. Signed-off-by: Brian Gernhardt <> Signed-off-by: Junio C Hamano <>
2007-04-16Documentation: clarify track/no-track option.J. Bruce Fields
Fix the description of the --no-track option so it no longer says the opposite of what was intended. Also mention branch.autosetupmerge explicitly. Signed-off-by: "J. Bruce Fields" <> Signed-off-by: Junio C Hamano <>
2007-04-16Documentation: clarify git-checkout -f, minor editingJ. Bruce Fields
"Force a re-read of everything" doesn't mean much to me. Also some minor grammar fixes. Signed-off-by: "J. Bruce Fields" <> Signed-off-by: Junio C Hamano <>
2007-03-11git-branch, git-checkout: autosetup for remote branch trackingPaolo Bonzini
In order to track and build on top of a branch 'topic' you track from your upstream repository, you often would end up doing this sequence: git checkout -b mytopic origin/topic git config --add branch.mytopic.remote origin git config --add branch.mytopic.merge refs/heads/topic This would first fork your own 'mytopic' branch from the 'topic' branch you track from the 'origin' repository; then it would set up two configuration variables so that 'git pull' without parameters does the right thing while you are on your own 'mytopic' branch. This commit adds a --track option to git-branch, so that "git branch --track mytopic origin/topic" performs the latter two actions when creating your 'mytopic' branch. If the configuration variable branch.autosetupmerge is set to true, you do not have to pass the --track option explicitly; further patches in this series allow setting the variable with a "git remote add" option. The configuration variable is off by default, and there is a --no-track option to countermand it even if the variable is set. Signed-off-by: Paolo Bonzini <> Signed-off-by: Junio C Hamano <>
2007-02-17Convert update-index references in docs to add.Shawn O. Pearce
Since `git add` is the approved porcelain for an end-user to invoke when they want to manipulate the index, porcelain documentation should steer the user to this command rather than the pure plumbing update-index. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-02-13Documentation: Moving out of detached HEAD does not warn anymore.Junio C Hamano
The documentation still talked about the unnecessary 'safety' in git-checkout. Pointed out by Matthias Lederhofer. Signed-off-by: Junio C Hamano <>
2007-02-02add a quiet option to git-checkoutNicolas Pitre
Those new messages are certainly nice, but there might be cases where they are simply unwelcome, like when git-commit is used within scripts. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>