----- Original Message -----
From: Matthieu Moy
Date: 1/21/2011 10:05 AM
Junio C Hamano<gitster@xxxxxxxxx> writes:
Johannes Schindelin<Johannes.Schindelin@xxxxxx> writes:
Wouldn't that suggest us that if we were to do anything to this message
it would be a good idea to teach the user to "reset --hard" the branch
if no commits truly needs to be replayed on top of the onto-commit?
The important difference between rebase -i&& noop on the one, and reset
--hard on the other hand is that the latter is completely unsafe. I mean,
utterly completely super-unsafe. And I say that because _this here
developer_ who is not exactly a Git noob lost stuff that way.
I think "rebase" already checks that the index and the working tree is
clean before starting, so referring to "reset --hard" when "rebase -i"
notices there is absolutely nothing to do is _not_ unsafe, no?
The point is not about letting rebase do a "reset --hard", but to tell
the user s/he should have ran "reset --hard" instead of rebase. The
danger is to teach the user's fingers to type "reset --hard" too
often, which is unsafe ;-).
I've always wished "git reset --hard" would tell me there are modified
files and force me to type "git reset --hard --force" to overwrite
them. It is a dangerous command, and I stupidly run it sometimes
without running "git status" first.
-Josh
--
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