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

From: Charvi Mendiratta <charvi077@gmail.com>
Date: Feb 21, 2021, 06:35 UTC
Message-ID: <CAPSFM5cRq9OfxypwTAsv3OFpTPM88e4_agTmFEGbaVyLi6Qbig@mail.gmail.com>
In-Reply-To: <xmqq4ki7bf9y.fsf@gitster.g>

Hi,

On Sat, 20 Feb 2021 at 08:46, Junio C Hamano <gitster@pobox.com> wrote:

Show 28 quoted lines

>
> Charvi Mendiratta <charvi077@gmail.com> writes:
>
> > 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.

Show 20 quoted lines

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

Show 16 quoted lines

> 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