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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2021, 17:35 UTC
Message-ID: <xmqqft1o80pe.fsf@gitster.g>
In-Reply-To: <CAPSFM5dZ=CR21eqE7Y-4AssD9h0ddnUYpy4PSzWVaf8kzsLv_g@mail.gmail.com>

Charvi Mendiratta <charvi077@gmail.com> writes:

Show 8 quoted lines

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

Show 8 quoted lines

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