No, use that only if you want to throw away everything you did after
that particular point.
If you just want to go and look at it more closely, with git-1.5 you do
git checkout <SHA>
which will just detatch your HEAD from any current branch, and just move
you there. But with an older git that doesn't like the detached state,
you'd could instead do
git checkout -b nonlame-branch <SHA>
which actually creates a new branch with the <SHA> as the beginning point,
and switches to it. That will work with any version (including 1.5, of
course).
You can then decide to re-do the branch without the lame commit. One
particularly simple thing to do (if it's just one lame commit, and you
don't want to *remove* it, but just fix it up a bit) is to literally check
out the tip of tree juat AT the lame commit, and then you can use
git commit --amend
to actually change it.
So depending on what your situation is, this sequence actually works:
#
# Create and check out a "fixes" branch that has the
# known-broken commit as its head commit
#
git checkout -b fixes <BROKEN-COMMIT>
.. edit edit edit to fix the broken commit ..
#
# Then, just _replace_ the broken commit with the fixed state
# by doing a "git commit --amend"
#
git commit -a --amend
#
# ok, now the "fixed-branch" is in good shape, but we
# want to re-surrect our original 'master' branch WITH the
# fix, and based on the fixed branch, so we rebase the
# master branch# _onto_ the fixed state in "fixes", with
# the broken commit (that we do _not_ want to include) as
# the base.
#
git rebase --onto fixes <BROKEN-COMMIT> master
Somebody else should verify that "git rebase" thing. I still find the
syntax for that thing rather illogical for these kinds of things.
Possibly because I never do it myself.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
