Hi,

On Sat, 20 Feb 2021 at 08:46, Junio C Hamano [off-list ref] wrote:

Charvi Mendiratta [off-list ref] writes:

quoted

For end-users "-m" or "-F" will make it easier to prepare an "amend!"
commit. Because using the "-m" reduces the cost of opening an editor
to prepare "amend!" commit and it can be done with command line only.

Hmph.  That is not very convicing to me.  The user is motivated
enough to fix a wrong commit log message and replace it with an
improved one by using the "--fixup:amend" feature---why would that
improved message can sufficiently be written with just an "-m
message", which by definition would be much less capable of
preparing a well-thought-out message than with an editor?

Yes, with "-m", you can add some short string easily at the end of
the existing commit message without opening an editor.  But I am
trying to see why it is a good thing to be able to do so in the
first place.  It is very easy to make typoes while doing so and it
would be hard to fix these typoes, exactly because you are doing so
without being in an editor.  And the whole point of --fixup=amend is
about improving the message (as opposed to --fixup that is to record
the contents that have already been improved in the index).

This is why I kept asking what the use case would look like.  I am
trying to find out if you have a good end-user story in mind that we
can use in the documentation to sell the feature to end-users, but I
am not seeing one.

I was in my mind that, as we can easily prepare the commit using `git
commit -m "commit message"`. Similarly, we can extend this working
with `git commit --fixup=amend:<commit> -m "new commit message"`. And
the difference is that in the later one the goal of changing the
commit message will be achieved after `git rebase --autosquash` i.e
the later command works with sequencer. This will easily allow us to
write a new message for the commit we are fixing up through the
command line only similar to `git commit -m` and if we need to fixup
the commit msg then it can be done without `-m` and the editor gets
open with a seeded commit message we want to fixup. Also the same
working applies to `reword` option also and may allow to reword the
commit msg from command line only.

But I am still doubtful, as I agree with above that the main concern
is to only fixup the wrong commit message and in that case the "-m"
option can't be that much productive or maybe confusing for users.

Is the combination of "--fixup=amend" and "-m <msg>" meant to be
used primarily "to leave a note to myself" when the user runs
--fixup=amend:<commit>, to just record the points to be elaborated
when the message is written for real much later?  E.g.

    ... hack hack hack ...
    ... good stopping point, but cannot afford time to write
    ... a good log message now
    $ git commit --fixup=amend:HEAD~2 -m 'talk about X, Y and Z' -a
    ... hack hack hack ...
    ... possibly doing something entirely different ...
    ... finally comes back to finish cleaning up the branch for real ...
    $ git rebase --autosquash -i origin

And one of the insn created in the todo sheet would be amend!, whose
commit message has the message taken from the original HEAD~2 PLUS the
reminder to the user that s/he needs to talk about X, Y and Z?  And
the user at that point writes more comprehensive message about these
three things?

But here in this case, after `git rebase --autosquash -i origin`, it
will not open editor again and user is not allowed to write more
comprehensive message about these three things, unless the user
manually changes from automatically converted `pick` to `fixup -C`,
to `fixup -c` command in the rebase todo list that gets opened after
`git rebase --autosquash`. And for this case `git commit --squash` is
more easy to use.

That is a made-up example of what "appending some short strings
possibly full of typoes without having to open an editor" could be
useful for.  I am not sure if it is truly useful, or if it is just a
hand wavy excuse not to mark -m/-F incompatible with --fixup=amend
without a real merit [*].

    Side note: one reason why I do not find it realistic is that it
    is unlikely that the user would use --fixup=amend to slurp in
    the original log message when recording "good stopping point,
    but cannot afford time" fixup.  "--squash HEAD~2 -m <msg>" would
    be much faster to record the "note to myself" reminder, and when
    the user finally comes back to clean things up, the amount of
    work to edit the original's message while looking at the "note
    to myself" appended at the end would not be any different in
    either workflow.

Yes, I also thought the same and agree with it.

In any case, that was the kind of answer(s) I was looking for when I
asked "what is this good for?" question.

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` ?

Thanks and Regards,
Charvi