On Thu, Nov 11, 2010 at 11:49 AM, Seth Robertson <in-gitvger@xxxxxxxx> wrote:
> -Seth Robertson
>
> HEAD@{27} was your original problem. You made the commit on @{32}
> then for some reason did (probably) a `git reset HEAD^` That was the
> source of all of your problems. You should only use `git reset` if
> you have not pushed and if you are very sure you want to get rid of a
> commit or changes. It is a powerful command and with great power
> comes great responsibility.
>
Hello Seth,
Thank you for your reply and cogent explanation. Yes, in fact, I did
do a "git reset HEAD^". Somewhere along the way, I decided that was a
way to make my working copy look like it did prior to a commit.
I thought that git reset only affected HEAD. I didn't realize that it
also affected the branch pointer.
Your "great power, great responsibility" comment will make me treat
"git reset" with a lot more fear and respect.
It is confusing though, because I frequently see advice (such as that
offered by Jonathan Nieder (and very much appreciated, by the way) to
do things like:
$ git merge --no-commit
$ git reset
Why is that "git reset" benign, when the "git reset HEAD^" wasn't benign before?
--wpd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html