git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Charvi Mendiratta <charvi077@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Christian Couder <chriscool@tuxfamily.org>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 2/6] commit: add amend suboption to --fixup to create amend! commit
Date: Sun, 21 Feb 2021 12:05:29 +0530	[thread overview]
Message-ID: <CAPSFM5cRq9OfxypwTAsv3OFpTPM88e4_agTmFEGbaVyLi6Qbig@mail.gmail.com> (raw)
In-Reply-To: <xmqq4ki7bf9y.fsf@gitster.g>

Hi,

On Sat, 20 Feb 2021 at 08:46, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

> 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

  reply	other threads:[~2021-02-21  6:41 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17  7:29 [PATCH 0/6][Outreachy] commit: Implementation of "amend!" commit Charvi Mendiratta
2021-02-17  7:37 ` [PATCH 1/6] sequencer: export subject_length() Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 2/6] commit: add amend suboption to --fixup to create amend! commit Charvi Mendiratta
2021-02-17 19:49     ` Junio C Hamano
2021-02-18 10:13       ` Charvi Mendiratta
2021-02-18 19:18         ` Junio C Hamano
2021-02-18 20:37           ` Junio C Hamano
2021-02-19  6:10             ` Charvi Mendiratta
2021-02-19  6:09           ` Charvi Mendiratta
2021-02-20  3:15             ` Junio C Hamano
2021-02-21  6:35               ` Charvi Mendiratta [this message]
2021-02-21  7:05                 ` Junio C Hamano
2021-02-21  9:20                   ` Charvi Mendiratta
2021-02-22 17:35                     ` Junio C Hamano
2021-02-23  6:05                       ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 3/6] commit: add a reword suboption to --fixup Charvi Mendiratta
2021-02-17 19:56     ` Junio C Hamano
2021-02-18 10:14       ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 4/6] t7500: add tests for --fixup[amend|reword] options Charvi Mendiratta
2021-02-17 19:59     ` Junio C Hamano
2021-02-18 10:15       ` Charvi Mendiratta
2021-02-18 19:26         ` Junio C Hamano
2021-02-19  6:10           ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 5/6] t3437: use --fixup with options to create amend! commit Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 6/6] doc/git-commit: add documentation for fixup[amend|reword] options Charvi Mendiratta
2021-02-18 19:23     ` Junio C Hamano
2021-02-19  6:09       ` Charvi Mendiratta
2021-02-23 19:55 ` [PATCH 0/6][Outreachy] commit: Implementation of "amend!" commit Junio C Hamano
2021-02-24  5:54   ` Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 " Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 1/6] sequencer: export subject_length() Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 2/6] commit: add amend suboption to --fixup to create amend! commit Charvi Mendiratta
2021-02-25 21:00   ` Junio C Hamano
2021-02-26 10:38     ` Charvi Mendiratta
2021-02-26 19:32       ` Junio C Hamano
2021-02-27  4:56         ` Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 3/6] commit: add a reword suboption to --fixup Charvi Mendiratta
2021-02-25 20:32   ` Junio C Hamano
2021-02-26 10:35     ` Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 4/6] t7500: add tests for --fixup=[amend|reword] options Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 5/6] t3437: use --fixup with options to create amend! commit Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 6/6] doc/git-commit: add documentation for fixup=[amend|reword] options Charvi Mendiratta
2021-02-25 20:48   ` Junio C Hamano
2021-02-26 10:36     ` Charvi Mendiratta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPSFM5cRq9OfxypwTAsv3OFpTPM88e4_agTmFEGbaVyLi6Qbig@mail.gmail.com \
    --to=charvi077@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood123@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).