Re: [PATCH 2/6] commit: add amend suboption to --fixup to create amend! commit

Charvi Mendiratta [off-list ref] writes:

quoted

 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 ....

If we were to make -m/-F incompatible with these new features, then
sure, we'd notice the combination, show an error message and abort.

quoted

than just accepting and doing useless thing, I am OK
if we left them as they are.

....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.

What would that more precise documentation would say, though?  

"'-m message' gets appended to the message taken from the original
commit"?  Saying that alone, without explaining why doing such an
appending is useful, would puzzle users and makes them ask "but why
such a useless feature exist?" and that was why I was trying to
figure out what it is useful for with you, which I think we have
failed to do so far.

My preference at this point is to error out the combination that we
cannot figure out how it could be useful at this moment, so that
users who find how it would be useful to come to us and present a
hopefully good case for using -m <msg> with --fixup=amend:<commit>.
I am assuming that allowing the combination at that point is easy,
and the user request will give us a good use case we can use in the
documentation to explain for what purpose a user may want to use -m
<msg> to append a short string at the end.  The end users' use case
we see at that point might even suggest that it would be more useful
to prepend (as opposed to append) the message we get from -m <msg>
to the original log message, and such a change will not be possible
if we just choose to append without thinking through the use case we
intend to support and release "we do not know what good it would do
to append with -m <msg>, but that is what the code happens to do now"
version to the users, as people will depend on the behaviour of any
released versions.

On Mon, 22 Feb 2021 at 23:05, Junio C Hamano [off-list ref] wrote:
[...]

If we were to make -m/-F incompatible with these new features, then
sure, we'd notice the combination, show an error message and abort.

quoted

quoted

than just accepting and doing useless thing, I am OK
if we left them as they are.

....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.

What would that more precise documentation would say, though?

"'-m message' gets appended to the message taken from the original
commit"?  Saying that alone, without explaining why doing such an
appending is useful, would puzzle users and makes them ask "but why
such a useless feature exist?" and that was why I was trying to
figure out what it is useful for with you, which I think we have
failed to do so far.

My preference at this point is to error out the combination that we
cannot figure out how it could be useful at this moment, so that
users who find how it would be useful to come to us and present a
hopefully good case for using -m <msg> with --fixup=amend:<commit>.
I am assuming that allowing the combination at that point is easy,
and the user request will give us a good use case we can use in the
documentation to explain for what purpose a user may want to use -m
<msg> to append a short string at the end.  The end users' use case
we see at that point might even suggest that it would be more useful
to prepend (as opposed to append) the message we get from -m <msg>
to the original log message, and such a change will not be possible
if we just choose to append without thinking through the use case we
intend to support and release "we do not know what good it would do
to append with -m <msg>, but that is what the code happens to do now"
version to the users, as people will depend on the behaviour of any
released versions.

Okay, I admit prepending the msg can be another way. Thanks a lot for
clarifying in detail, I completely agree with it and will error out
the combination for now.

Thanks and Regards,
Charvi