Junio C Hamano <gitster@xxxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> writes: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> ... >>> You can do: >>> >>> $ git reset HEAD^ >>> $ git commit -m "blah" >>> >>> if you do not want to reuse the commit message. >> >> You can pretty much _always_ avoid --amend in a similar manner, but >> why would you? It is convenient. > > No need to be upset about what I said. I really do not want to > change the minor detail this late in the 1.5.3 release cycle, and > wanted to unblock you by giving an workaround in case you were > stuck. Well, there is always VISUAL='echo "mycommit" >"$1"' git commit --amend Uh, no wait, it isn't. Different thread. > It should be a straightforward change to git-commit.sh. Instead of > "Oops, -m and --amend are incompatible so we will whine" around line > 300, you can treat --amend somewhat specially by (1) making it first > not set log_given, which would still keep the combination of > -m/-c/-C/-F incompatible, (2) when $log_given is false and we are > amending, honor $use_commit to prime the message. I actually can't find anything about (2) to be done in the code. > Then you can keep the current bahaviour for amending starting from > the existing message, while allowing -m/-c/-C/-F to supply different > message for the replacing commit. In a somewhat different vein: it appears strange that -m is treated completely different from the other commit message specifiers: you can specify -m multiple times. I have not changed this in the slightly tested patch posted separately: while the --amend fix was quite straightforward and confined (and indeed, not even the documentation appears to warrant any modification), the m/t mess is something I really don't want to mess with right now. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
