Carlos Rica <jasampler@xxxxxxxxx> writes: > Also, this removes those tests ensuring that repeated > -m options don't allocate memory more than once, because now > this is done after parsing options, using the last one > when more are given. The same for -F. The reason for this change is...? Is this because it is cumbersome to detect and refuse multiple -m options using the parseopt API? If so, the API may be what needs to be fixed. Taking the last one and discarding earlier ones feels to me an arbitrary choice. While I freely admit that I do not particularly find the "One -m introduces one new line, concatenated to form the final paragraph" handling of multiple -m options done by git-commit nice nor useful, I suspect that it would make more sense to make git-tag and git-commit handle multiple -m option consistently, if you are going to change the existing semantics. Since some people really seem to like multiple -m handling of git-commit, the avenue of the least resistance for better consistency would be to accept and concatenate (with LF in between) multiple -m options. With multiple -F, I think erroring out would be the sensible thing to do, but some people might prefer concatenation. I do not care either way as long as commit and tag behave consistently. - 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
