Alex Riesen <raa.lkml@xxxxxxxxx> writes: >> Having said that, here is a quiz. When the user says "git >> commit --amend", what are the valid reasons not to allow it, >> other than: >> >> - the index is unmerged. >> - the branch is yet to be born. > > There are no tree changes in the commit to be amended. > And if there is a strong wish to do just the amendment, > there is always --allow-empty. If the original commit had some changes, but the final tree, after hacking, experimenting and fixing, ended up in the same shape as the parent's, the user might rather want to "reset HEAD^" away the commit than amending now-empty commit. Erroring out when --allow-empty is not given (like we currently do) would be sensible in such a case. However, if the original commit was made with --allow-empty, it might have been done for a reason, and I was not sure if forcing the user to say --allow-empty while amending (like we currently do) was such a good idea. The user previously may have created that empty (in content changes) commit to piss in the snow, or perhaps the empty commit is due to foreign SCM import, and the user may be trying to improve the log message that is attached to it. The user might even be an automated script in the case of foreign SCM import, but admittedly, it could choose to always say --allow-empty. That was the motivation behind that quiz. - 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
