Charvi Mendiratta <charvi077@xxxxxxxxx> writes: > Thanks a lot for explaining each perspective in detail. So, now if we > use `-m` as an option to write side-note then `--squash` is already > available and for fixing the commit message opening the editor is a > must expected option. So shall we remove the `-m` option compatibility > if `amend`/ `reword` suboptions are passed to `git commit --fixup` ? FWIW, I do not have a strong opposition against -m/-F that is not rejected when --fixup=amend is in use. It is OK for Git to accept useless combinations of options that do not help end-users. A combination that is not useful will be left unused, which is not a great loss. So, if it is more work to make the code notice when these options are given in useless combinations and stop with an error message than just accepting and doing useless thing, I am OK if we left them as they are. I was just hoping that letting "-m <message>" and "--fixup=amend" used at the same time would support a great use case, and because I didn't think of any, I asked the person who allowed the combination (that is you) what the intended use cases are. Actively supporting a combination because it gives users great value is more satisfying than just leaving useless combination to exist only because it does not actively hurt. When users say "The command can take these two options at the same time, but I cannot figure out what good the combination is for. It feels utterly useless to use them together" it also is much easier to answer them if we can say "because by using these two together, you can do this great thing" instead of having to say "we do not think it makes much sense to use these two options together." Thanks.
