What does the ~1 mean in this git reset command? -

git reset head~1

i under impression ~1 meant: start @ head, follow 1 link, , set head tag new commit node. expecting

git reset head~2

to follow 2 links , set head tag. however, if try it, error:

$ git reflog c83bbda head@{0}: reset: moving head~1 44c3540 head@{1}: commit: garbage c83bbda head@{2}: reset: moving head~1 aee7955 head@{3}: commit: 4 lines c83bbda head@{4}: reset: moving head~1 19ec1d5 head@{5}: commit: 3 lines c83bbda head@{6}: reset: moving head~1 a049538 head@{7}: commit: added new line c83bbda head@{8}: commit (initial): first commit   $ git reset --hard head~2 fatal: ambiguous argument 'head~2': unknown revision or path not in working tree. use '--' separate paths revisions, this: 'git <command> [<revision>...] -- [<file>...]' 

apparently mistaken, doc page git reset not useful in clarifying this. so, ~1 mean , why need it?

head~1 "the first parent of head", while head~2 "the first parent of first parent of head, , on (so head~n n head followed n ^ symbols , no numbers). again, specifics in git-rev-parse manual page.

be careful when mixing git reset "revisions counting backwards head". git reset will, in general, change value of head, e.g.:

$ git checkout master    # on tip of "master" branch $ git branch save master # copy branch tip label, safekeeping $ git reset head^        # or git reset head~1 

moves head (and master) first parent. way name parent save^, , yet save~1. after move finishes, though, head names parent revision, head^ names its parent:

$ git reset head^ 

moves step, master , head name same commit save~2 names. easy see using git rev-parse, tells commit-id symbolic-name maps to:

$ git rev-parse save~2 master 0f5a13497dd3da8aff8e452c8f56630f83253e79 0f5a13497dd3da8aff8e452c8f56630f83253e79 

at point, can restore master save-point with:

$ git reset save 

which moves head , master saved revision, , can delete save safely if like:

$ git branch -d save 

note save save-point git tag too: difference between branch , tag behavior of new check-ins when "on branch" (tags don't move, branches do) , check-outs (tags put in "detached head" = not-on-a-branch state, branch names put in "on-a-branch" state).