Charvi Mendiratta [off-list ref] 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.
On Sun, 21 Feb 2021 at 12:35, Junio C Hamano [off-list ref] wrote:
Charvi Mendiratta [off-list ref] writes:
quoted
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
Sorry I didn't get this and would like to once confirm here that, are
you pointing to output an error message when the `-m`/`-F` option is
passed with `git --fixup=amend/reword` ? Because I think we can do
this also. Otherwise ....
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."
....If we allow both `m` and `F` to work with `git commit
--fixup=amend/reword` with the same working as it is doing now i.e to
use `m` to write new commit message, upon `--autosquash`, If it is
okay? then I also agree to update the documentation more precisely and
include the uses when passed with `m` /`F`(not yet added) option.
(Please correct me if I am wrong)
Thanks and Regards,
Charvi