SYNOPSIS
--------
[verse]
-'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
-'git-checkout' [<
branch>] <paths>...
+'git-checkout' [-q] [-f] [-b [--track | --no-track] <new_branch> [-l]] [-m] [<branch>]
+'git-checkout' [<
tree-ish>] <paths>...
DESCRIPTION
-----------
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
specified, <new_branch>. Using -b will cause <new_branch> to
-be created.
+be created; in this case you can use the --track or --no-track
+options, which will be passed to `git branch`.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
-the index file (i.e. it runs `git-checkout-index -f -u`). In
+the index file (i.e. it runs `git-checkout-index -f -u`), or a
+named commit. In
this case, `-f` and `-b` options are meaningless and giving
-either of them results in an error. <branch> argument can be
-used to specify a specific tree-ish to update the index for the
-given paths before updating the working tree.
+either of them results in an error. <tree-ish> argument can be
+used to specify a specific tree-ish (i.e. commit, tag or tree)
+to update the index for the given paths before updating the
+working tree.
OPTIONS
-------
+-q::
+ Quiet, supress feedback messages.
+
-f::
Force a re-read of everything.
by gitlink:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
+--track::
+ When -b is given and a branch is created off a remote branch,
+ setup so that git-pull will automatically retrieve data from
+ the remote branch.
+
+--no-track::
+ When -b is given and a branch is created off a remote branch,
+ force that git-pull will automatically retrieve data from
+ the remote branch independent of the configuration settings.
+
-l::
Create the new branch's ref log. This activates recording of
all changes to made the branch ref, enabling use of date
+
When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
-and mark the resolved paths with `git update-index`.
+and mark the resolved paths with `git add` (or `git rm` if the merge
+should result in deletion of the path).
<new_branch>::
Name for the new branch.
What this means is that you can discard your temporary commits
and merges by switching back to an existing branch (e.g. `git
checkout master`), and a later `git prune` or `git gc` would
-garbage-collect them.
-
-The command would refuse to switch back to make sure that you do
-not discard your temporary state by mistake when your detached
-HEAD is not pointed at by any existing ref. If you did want to
-save your state (e.g. "I was interested in the fifth commit from
-the top of 'master' branch", or "I made two commits to fix minor
-bugs while on a detached HEAD" -- and if you do not want to lose
-these facts), you can create a new branch and switch to it with
-`git checkout -b newbranch` so that you can keep building on
-that state, or tag it first so that you can come back to it
-later and switch to the branch you wanted to switch to with `git
-tag that_state; git checkout master`. On the other hand, if you
-did want to discard the temporary state, you can give `-f`
-option (e.g. `git checkout -f master`) to override this
-behaviour.
+garbage-collect them. If you did this by mistake, you can ask
+the reflog for HEAD where you were, e.g.
+
+------------
+$ git log -g -2 HEAD
+------------
EXAMPLES
At this point, `git diff` shows the changes cleanly merged as in
the previous example, as well as the changes in the conflicted
files. Edit and resolve the conflict and mark it resolved with
-`git update-index` as usual:
+`git add` as usual:
+
------------
$ edit frotz
-$ git update-index frotz
+$ git add frotz
------------