Mark Wooding <mdw@xxxxxxxxxxxxxxxx> writes: > Currently -c (copy some other commit message, and then edit it) is > considered to be a `force message to be...' kind of option, like the > others I've listed above. > > So, for some reason, is --amend. This last is really annoying. I think the mindset is a bit different. The -C/-c options are about the latter half of cherry-picking. The user asks "reuse the message from an existing commit so that I do not have to type", or "I could reuse the original log message almost as-is, but I am using the change in a slightly different context from the original commit (and that is why cherry-pick did not finish by itself and you need to run git-commit after fixing up), so I would need to talk a bit about what I did in the fix-up in the log message". Both are useful. Amend is conflated -- you are amending what you did, either perhaps you found a small typo in the code in which case the difference between what is being amended and what will be committed may only be the tree and you would want to re-use an existing message as-is, or you found a small typo in the log message in which case there won't be any difference in the trees but you do want to spellfix the log message, or you may be fixing both. We happen default to the edit behaviour for no particular reason, other than "because :q or C-x # are cheap". Unfortunatly there is no good default for this case -- fixing tree and fixing message are both almost equally often used in the real world, so changing --amend not to let you edit by default and adding --edit option would inconvenience other use case. Adding --no-edit option is not very nice either. It's almost as cumbersome to type as "EDITOR=:". What you want might be an --amend-tree option; it would be to the --amend option what the -C (--reuse-message) option is to the -c (--reedit-message). - 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