Information Technology Reference
In-Depth Information
You can treat the
$ git reset --mixed
operation as the reverse of staging
and committing. Here are the internals described in terms of three snapshots:
• Modification of
HEAD
:updatethe
HEAD
sothatitpointsto
[REVISION]
• Modification of the staging area: take the snapshot that is now pointed by
the
HEAD
and store it in the staging area
• Do not touch the working area
Right now it is easy to analyze the command presented in this recipe:
$ git re-
set HEAD
∼
. The command is equivalent to
$ git reset --mixed HEAD
∼
. It
performs two operations:
• Sets the
HEAD
so that it points to the parent revision
• It takes the snapshot so that it is now pointed by
HEAD
and stores it in the
staging area.
Notice that the working directory is not changed. All your modifications (they were
already committed) remain there. The result is exactly as it was before you staged and
committed changes. The three files
b.txt
,
c.txt
, and
d.txt
are now displayed as
unstaged.
The third option,
--soft
, only moves the pointer stored in
HEAD
. It does not
modify the staging area or the working directory. If you try to use
$ git reset --
soft HEAD
∼
in this recipe, then the state returned by
$ git status -sb
would
be:
A_ b.txt
A_ c.txt
A_ d.txt
The files are staged. If you want to create a revision that stores only one file you
have to unstage some files. To change the
c.txt
file from
A_
into
_A
you can use the
$ git rm --cached c.txt
command. The alternative way to perform the
$
git reset HEAD
∼
is to use two commands:
$ git reset --soft HEAD
∼
$ git rm --cached [b-d].txt
