How do I undo a fast-forward merge safely?

I had done a git merge --no-commit <source_branch> operation, but that
bit me because I mistakingly concluded that --no-commit would prevent
any type of automatic operation, but apparently a fast-forward
occurred.  I should have used the --no-ff option? How do I get my
target branch back to where it was before the bad merge?

I did make a backup of the entire repo before I started, so I do have
the plan-B option of replay my changes onto a copy of the backup repo.
  But, maintaining backup copies just so as to avoid getting bit each
time I forget to use the --no-ff option will be a non-starter, so I
would hope there are some safe commands I can use to go back to the
original.

git log -1 does not show the commit, but gitk does show a vertical red
line that I can only presume indicates the fast-forward.  How does
gitk determine that red line, while git-log does not?  Note that I
have not pulled into any other repo's yet, and won't until I can
rectify this issue.

Here was my bad git merge command line:

$ git merge --no-commit source_branch
Updating 7eb9a02..0c66ca1
Fast forward
<eliding list of files I want mixed in with lots of files I don't want>

So, what operations, rebase, reset, etc, do I need to do to get this
repo back to where it was right before the fast-forward?

Thanks,
Brent

Brent Goodrick [off-list ref] writes:

I had done a git merge --no-commit <source_branch> operation, but that
bit me because I mistakingly concluded that --no-commit would prevent
any type of automatic operation, but apparently a fast-forward
occurred.  I should have used the --no-ff option? How do I get my
target branch back to where it was before the bad merge?

[...]

So, what operations, rebase, reset, etc, do I need to do to get this
repo back to where it was right before the fast-forward?

Each 'large' operation sets ORIG_HEAD

  $ git reset --hard ORIG_HEAD

If you want to be more careful, examine reflog for HEAD, using either
"git reflog" or "git log -g", and you can reset to previous version of
HEAD (i.e. where current branch pointed to before 'git fetch') with

  $ git reset --hard HEAD@{1}

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Sun, Feb 22, 2009 at 11:54 AM, Jakub Narebski [off-list ref] wrote:

quoted

So, what operations, rebase, reset, etc, do I need to do to get this
repo back to where it was right before the fast-forward?

Each 'large' operation sets ORIG_HEAD

 $ git reset --hard ORIG_HEAD

Thanks Jakub. "git reset --hard ORIG_HEAD" was what I went with and it
worked like a charm!

bg