ZheNing Hu <adlternative@xxxxxxxxx> writes: >> It might be desirable to make it easier for people to migrate from >> ".command" to ".cmd". I agree this is debatable, but I don't see a big >> downside in it. Maybe, if no argument was passed at all the first time >> the command is called instead of the empty string, the command could >> then know that it's called for the first time. I am not sure this >> would be very helpful in practice though. >> > > If i'm not wrong, Christan meant that this command must run so it's > "consistency", and Junio thinks this "consistency" is not needed. My stance actually is a bit stronger than that. I suspect that running the command without argument once even when no --trailer on the command line asks for that <key> is a misfeature, if not a bug (only because it is now documented by 1/2 as such---before that, at least I did not read the document that way). And unless it is shown that it is not a misfeature but is a useful behaviour with an example use case that benefits from it, I would prefer not to replicate it in the ".cmd". > It is true that there is not much harm in keeping `.cmd` at the behavior > of `.command` now. It is far from "there is not much harm". It misses the whole point of the exercise. Only replacing the first occurrence and not the second and subsequent occurrence is not what we are keeping in ".cmd". Replacing in an unsafe way with respect to the command line syntax is not what we are keeping in ".cmd". That is because these two are misfeatures if not bugs (only because they are documented). In fact, the only reason why we are introducing .cmd is so that we can deprecate .command and get rid of its misfeatures while keeping only good bits. So I am waiting to hear why it is not a misfeature. If it is not, then surely I am fine to keep it for now and add a workaround later, but until that happens, I do not think "commit --trailer" can be used as a way to allow end-users emulate "-s" for their favorite trailer like helped-by, acked-by, etc.
