Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> No. If not saving, then it means that the user was fine with the message
> as-is.
>
> Remember, --amend is usually for amending the _content_ of the patch, not
> so much the message.
I very often use --amend to update only the message, so I would strongly
disagree with the "usually".
But that doesn't change my conclusion ;-) It is immaterial if you amended
the tree or the message. If either or both changed, we do need to create
a new commit---there is no question about it, so which one is more often
done does not matter. Eugene does not gain anything by "Remember"ing it.
What is more important is what to do when neither changed.
If you run "rebase -i" and leave the earlier "pick"s intact, it seems to
try keeping the commits intact, instead of rewriting.
It is understandable if somebody wanted to keep using the old commit
object when the committer timestamp is the _only_ thing that is different
between the original and the amended commit, after "git commit --amend" is
run. Essentially, the behaviour of "rebase -i" for earlier "pick"s comes
from the same motivation.
Right now, if you run this in a loop:
while hell has not frozen over
do
git reset && EDITOR=: git commit --amend
done
it will keep generating almost identical commits, except for their
committer timestamps. The very first one may have different committer
identity from the original if you are amending somebody else's commit, but
after that it will be all you over and over again, only at different
times.
I am inclined to say that it is a feature that it updates the commit in
such a case to record the _last time_ you touched the commit. You ran
"commit --amend" and did not use the any published method to _abort_ the
amend.
As mentioned already, @{1} is your friend. Regardless of the difference
between @{0} and @{1}, it is a way to go back to the previous commit if
you do not like the latest commit for whatever reason; the latest commit
may have a "wrong tree", a "wrong message", or a "wrong committer
timestamp".
--
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