Re: How to recover a lost commit...

Patrick Doyle wrote:

Right. In general, git operations that update HEAD also tend to take the current branch along with them. So:

	# update the current branch to include a new commit
	git commit

	# update the current branch to include a change from another branch
	git cherry-pick --ff $rev

	# update the current branch to incorporate the history of another branch
	git merge $rev

	# reset the current branch head to match _that_ commit
	git reset --keep $rev

	# only reset the current branch head; index and worktree will be untouched
	git reset --soft $rev

If you want to use such an operation without updating a certain branch, then switch to a different branch.

	# switch branches: we are following 'topic' now
	git checkout topic

	# detach from all branches: we are building unanchored history now
	git checkout HEAD^0

See the section DETACHED HEAD from the "git checkout" manual for details.

Once you're used to it, it is not so scary. If you pass paths to "git reset", it will not change HEAD; instead, it changes the content registered in the index:

	git reset some-crazy-old-commit -- foo.c bar.c baz.c
	git diff --cached

If you do not pass paths, it will update HEAD to point to the specified commit.

	# the last commit was bad; discard it
	git reset --keep HEAD^

	# I'm totally lost.  Let's just start over, based on the version
	# that worked from yesterday.
	git reset --hard @{yesterday}

	# specialized operation: the tracked content of all files should
	# be used as a single commit on top of some other revision
	git reset --soft $new_parent
	git commit

	# less strange way to do about the same thing
	git reset $new_parent
	git diff;	# looks good?
	git add -u
	git commit

If you do not pass paths and do not pass a revision arg, this means you wanted to update HEAD to point to the commit it is already at. In other words, with --soft or --keep this is basically a noop, with --hard it discards any changes in working-tree files you haven't committed, with no operation mode arg it makes the index match the HEAD commit.

There should be a revision argument after "git merge --no-commit".

This "git reset" is equivalent to "git reset HEAD": it resets the index to match the current commit, so the changes applied by the merge appear as local changes.

Regards, Jonathan