Documentation / git-stash.txton commit doc/read-tree: remove obsolete remark (30221a3)
   1git-stash(1)
   2============
   3
   4NAME
   5----
   6git-stash - Stash the changes in a dirty working directory away
   7
   8SYNOPSIS
   9--------
  10[verse]
  11'git stash' list [<options>]
  12'git stash' show [<stash>]
  13'git stash' drop [-q|--quiet] [<stash>]
  14'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
  15'git stash' branch <branchname> [<stash>]
  16'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
  17             [-u|--include-untracked] [-a|--all] [<message>]]
  18'git stash' clear
  19'git stash' create [<message>]
  20'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
  21
  22DESCRIPTION
  23-----------
  24
  25Use `git stash` when you want to record the current state of the
  26working directory and the index, but want to go back to a clean
  27working directory.  The command saves your local modifications away
  28and reverts the working directory to match the `HEAD` commit.
  29
  30The modifications stashed away by this command can be listed with
  31`git stash list`, inspected with `git stash show`, and restored
  32(potentially on top of a different commit) with `git stash apply`.
  33Calling `git stash` without any arguments is equivalent to `git stash save`.
  34A stash is by default listed as "WIP on 'branchname' ...", but
  35you can give a more descriptive message on the command line when
  36you create one.
  37
  38The latest stash you created is stored in `refs/stash`; older
  39stashes are found in the reflog of this reference and can be named using
  40the usual reflog syntax (e.g. `stash@{0}` is the most recently
  41created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
  42is also possible).
  43
  44OPTIONS
  45-------
  46
  47save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
  48
  49        Save your local modifications to a new 'stash', and run `git reset
  50        --hard` to revert them.  The <message> part is optional and gives
  51        the description along with the stashed state.  For quickly making
  52        a snapshot, you can omit _both_ "save" and <message>, but giving
  53        only <message> does not trigger this action to prevent a misspelled
  54        subcommand from making an unwanted stash.
  55+
  56If the `--keep-index` option is used, all changes already added to the
  57index are left intact.
  58+
  59If the `--include-untracked` option is used, all untracked files are also
  60stashed and then cleaned up with `git clean`, leaving the working directory
  61in a very clean state. If the `--all` option is used instead then the
  62ignored files are stashed and cleaned in addition to the untracked files.
  63+
  64With `--patch`, you can interactively select hunks from the diff
  65between HEAD and the working tree to be stashed.  The stash entry is
  66constructed such that its index state is the same as the index state
  67of your repository, and its worktree contains only the changes you
  68selected interactively.  The selected changes are then rolled back
  69from your worktree. See the ``Interactive Mode'' section of
  70linkgit:git-add[1] to learn how to operate the `--patch` mode.
  71+
  72The `--patch` option implies `--keep-index`.  You can use
  73`--no-keep-index` to override this.
  74
  75list [<options>]::
  76
  77        List the stashes that you currently have.  Each 'stash' is listed
  78        with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is
  79        the one before, etc.), the name of the branch that was current when the
  80        stash was made, and a short description of the commit the stash was
  81        based on.
  82+
  83----------------------------------------------------------------
  84stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
  85stash@{1}: On master: 9cc0589... Add git-stash
  86----------------------------------------------------------------
  87+
  88The command takes options applicable to the 'git log'
  89command to control what is shown and how. See linkgit:git-log[1].
  90
  91show [<stash>]::
  92
  93        Show the changes recorded in the stash as a diff between the
  94        stashed state and its original parent. When no `<stash>` is given,
  95        shows the latest one. By default, the command shows the diffstat, but
  96        it will accept any format known to 'git diff' (e.g., `git stash show
  97        -p stash@{1}` to view the second most recent stash in patch form).
  98        You can use stash.showStat and/or stash.showPatch config variables
  99        to change the default behavior.
 100
 101pop [--index] [-q|--quiet] [<stash>]::
 102
 103        Remove a single stashed state from the stash list and apply it
 104        on top of the current working tree state, i.e., do the inverse
 105        operation of `git stash save`. The working directory must
 106        match the index.
 107+
 108Applying the state can fail with conflicts; in this case, it is not
 109removed from the stash list. You need to resolve the conflicts by hand
 110and call `git stash drop` manually afterwards.
 111+
 112If the `--index` option is used, then tries to reinstate not only the working
 113tree's changes, but also the index's ones. However, this can fail, when you
 114have conflicts (which are stored in the index, where you therefore can no
 115longer apply the changes as they were originally).
 116+
 117When no `<stash>` is given, `stash@{0}` is assumed, otherwise `<stash>` must
 118be a reference of the form `stash@{<revision>}`.
 119
 120apply [--index] [-q|--quiet] [<stash>]::
 121
 122        Like `pop`, but do not remove the state from the stash list. Unlike `pop`,
 123        `<stash>` may be any commit that looks like a commit created by
 124        `stash save` or `stash create`.
 125
 126branch <branchname> [<stash>]::
 127
 128        Creates and checks out a new branch named `<branchname>` starting from
 129        the commit at which the `<stash>` was originally created, applies the
 130        changes recorded in `<stash>` to the new working tree and index.
 131        If that succeeds, and `<stash>` is a reference of the form
 132        `stash@{<revision>}`, it then drops the `<stash>`. When no `<stash>`
 133        is given, applies the latest one.
 134+
 135This is useful if the branch on which you ran `git stash save` has
 136changed enough that `git stash apply` fails due to conflicts. Since
 137the stash is applied on top of the commit that was HEAD at the time
 138`git stash` was run, it restores the originally stashed state with
 139no conflicts.
 140
 141clear::
 142        Remove all the stashed states. Note that those states will then
 143        be subject to pruning, and may be impossible to recover (see
 144        'Examples' below for a possible strategy).
 145
 146drop [-q|--quiet] [<stash>]::
 147
 148        Remove a single stashed state from the stash list. When no `<stash>`
 149        is given, it removes the latest one. i.e. `stash@{0}`, otherwise
 150        `<stash>` must be a valid stash log reference of the form
 151        `stash@{<revision>}`.
 152
 153create::
 154
 155        Create a stash (which is a regular commit object) and return its
 156        object name, without storing it anywhere in the ref namespace.
 157        This is intended to be useful for scripts.  It is probably not
 158        the command you want to use; see "save" above.
 159
 160store::
 161
 162        Store a given stash created via 'git stash create' (which is a
 163        dangling merge commit) in the stash ref, updating the stash
 164        reflog.  This is intended to be useful for scripts.  It is
 165        probably not the command you want to use; see "save" above.
 166
 167DISCUSSION
 168----------
 169
 170A stash is represented as a commit whose tree records the state of the
 171working directory, and its first parent is the commit at `HEAD` when
 172the stash was created.  The tree of the second parent records the
 173state of the index when the stash is made, and it is made a child of
 174the `HEAD` commit.  The ancestry graph looks like this:
 175
 176            .----W
 177           /    /
 178     -----H----I
 179
 180where `H` is the `HEAD` commit, `I` is a commit that records the state
 181of the index, and `W` is a commit that records the state of the working
 182tree.
 183
 184
 185EXAMPLES
 186--------
 187
 188Pulling into a dirty tree::
 189
 190When you are in the middle of something, you learn that there are
 191upstream changes that are possibly relevant to what you are
 192doing.  When your local changes do not conflict with the changes in
 193the upstream, a simple `git pull` will let you move forward.
 194+
 195However, there are cases in which your local changes do conflict with
 196the upstream changes, and `git pull` refuses to overwrite your
 197changes.  In such a case, you can stash your changes away,
 198perform a pull, and then unstash, like this:
 199+
 200----------------------------------------------------------------
 201$ git pull
 202 ...
 203file foobar not up to date, cannot merge.
 204$ git stash
 205$ git pull
 206$ git stash pop
 207----------------------------------------------------------------
 208
 209Interrupted workflow::
 210
 211When you are in the middle of something, your boss comes in and
 212demands that you fix something immediately.  Traditionally, you would
 213make a commit to a temporary branch to store your changes away, and
 214return to your original branch to make the emergency fix, like this:
 215+
 216----------------------------------------------------------------
 217# ... hack hack hack ...
 218$ git checkout -b my_wip
 219$ git commit -a -m "WIP"
 220$ git checkout master
 221$ edit emergency fix
 222$ git commit -a -m "Fix in a hurry"
 223$ git checkout my_wip
 224$ git reset --soft HEAD^
 225# ... continue hacking ...
 226----------------------------------------------------------------
 227+
 228You can use 'git stash' to simplify the above, like this:
 229+
 230----------------------------------------------------------------
 231# ... hack hack hack ...
 232$ git stash
 233$ edit emergency fix
 234$ git commit -a -m "Fix in a hurry"
 235$ git stash pop
 236# ... continue hacking ...
 237----------------------------------------------------------------
 238
 239Testing partial commits::
 240
 241You can use `git stash save --keep-index` when you want to make two or
 242more commits out of the changes in the work tree, and you want to test
 243each change before committing:
 244+
 245----------------------------------------------------------------
 246# ... hack hack hack ...
 247$ git add --patch foo            # add just first part to the index
 248$ git stash save --keep-index    # save all other changes to the stash
 249$ edit/build/test first part
 250$ git commit -m 'First part'     # commit fully tested change
 251$ git stash pop                  # prepare to work on all other changes
 252# ... repeat above five steps until one commit remains ...
 253$ edit/build/test remaining parts
 254$ git commit foo -m 'Remaining parts'
 255----------------------------------------------------------------
 256
 257Recovering stashes that were cleared/dropped erroneously::
 258
 259If you mistakenly drop or clear stashes, they cannot be recovered
 260through the normal safety mechanisms.  However, you can try the
 261following incantation to get a list of stashes that are still in your
 262repository, but not reachable any more:
 263+
 264----------------------------------------------------------------
 265git fsck --unreachable |
 266grep commit | cut -d\  -f3 |
 267xargs git log --merges --no-walk --grep=WIP
 268----------------------------------------------------------------
 269
 270
 271SEE ALSO
 272--------
 273linkgit:git-checkout[1],
 274linkgit:git-commit[1],
 275linkgit:git-reflog[1],
 276linkgit:git-reset[1]
 277
 278GIT
 279---
 280Part of the linkgit:git[1] suite