Re: How to implement the "amend!" commit ?

From: Charvi Mendiratta <charvi077@gmail.com>
Date: Jan 14, 2021, 08:06 UTC
Message-ID: <CAPSFM5c=BT2S_32FrfFO7x1EONgaRE0C_TREhaYZVi8F=oj17g@mail.gmail.com>
In-Reply-To: <X/864HdPtf1km0xZ@nand.local>

Hi Taylor,

On Wed, 13 Jan 2021 at 23:54, Taylor Blau <me@ttaylorr.com> wrote:

Show 31 quoted lines

>
> Hi Chavri,
>
> On Wed, Jan 13, 2021 at 06:45:25AM +0530, Charvi Mendiratta wrote:
> > Hi Everyone,
> >
> > Implementing "amend!" commit would be an alternative to the
> > fixup!/squash! commit that addresses the issue as opened here[1]. Also
> > the related patches[2], adds the options to `fixup` command in
> > interactive rebase and supports the "amend!" commit upon
> > `--autosquash`. Next, after discussing with Phillip and Christian,
> > there could be 3 possibilities to implement the "amend!" commit (UI):
>
> To make sure that I'm understanding correctly:
>
>   - Your series in [2] teaches the rebase directive 'fixup' two new
>     options: -C, and -c. Unlike of the option-less 'fixup' command,
>     these new options use the message from the fixup commit instead of
>     the original.
>
>     If I'm understanding correctly, this old-style sequence:
>
>         pick aaaaaaaaaa original
>         fixup bbbbbbbbbb fixup! new
>         exec git commit --amend -C bbbbbbbbbb --no-edit
>
>     should be equivalent to this one:
>
>         pick aaaaaaaaaa original
>         fixup -C bbbbbbbbbb fixup! new
>

Yes, `fixup -C ` works the same as above.

Show 8 quoted lines

>   - Separate from that, you are asking about how to implement an
>     "amend!" commit which would behave exactly as the 'fixup -C' variant
>     that you are proposing.
>
> We should clarify what you mean by "implement". I take it from the
> remainder of your message that you are really asking about how we should
> _expose_ this new 'fixup -C' command to users.
>

I apologize for the confusion. But yes you got right, by using "implement" I mean to ask regarding the user interface for "amend!" commit. So, if we choose to go with adding additional arguments like , `git commit --fixup= --amend`, then it will create a new "amend!" commit and in sequencer it will insert fixup -C, upon `git rebase -i --autosquash`.

Show 30 quoted lines

> > Firstly, the `--fixup=<commit>` to have option like,
> > `--fixup=reword/amend:<commit>`
> >
> > So, `git commit --fixup` can have 3 options:
> >
> > a) `--fixup=<commit>`, work as of now, make fixup! commit.
> > b) `--fixup=amend:<commit>`, make "amend!" commit, takes changes and
> > also opens the editor for a new message (Here it adds a new message to
> > amend! commit's message body and upon autosquash it will fixup up the
> > content and reword the original commit message i.e replaces the
> > original commit message with the "amend!" commit's message).
> > c) `--fixup=reword:<commit>`, makes (empty) "amend!" commit, do not
> > take changes and open the editor for a new message(Here, upon
> > autosquash it will just reword the original commit message).
>
> I think that this trio is a good path forward, but...
> `--fixup` behaving as it always has, which is good. Then it makes
> `--fixup=amend:<commit>` insert a 'fixup -C', and `--fixup=reword:<...>`
> insert a 'fixup -c'.
>
> > Secondly,
> > As an alternative to above, we can use `--fixup=<commit> --amend` and
> > `--fixup=<commit> --reword`.
>
> ...I think that this option is even better.
>
> Here '--fixup=<commit>' with '--amend' inserts a 'fixup -C' sequencer
> comamnd, and using the same instead with '--reword' inserts a 'fixup -c'
> sequencer command.
>

I think this would be a bit different. Here both the `--fixup=<commit> --amend` and `--fixup=<commit> --reword` would create a new "amend!" commit and at the same time also opens the editor for a new commit message. And in the sequencer both insert "fixup -C". So, here for '--reword', 'fixup -c' is not used in sequencer upon --autosquash, as we need to open the editor only one time while `git commit --fixup=<commit> --reword` and works as an alternative to "squash!" commit that opens the editor both the time.

And, the major difference is that " --fixup=<commit> --amend" would take both changes and also let the user change the commit message. On the other hand "--fixup=<commit> --reword" will not take any changes and only let the user to change the commit message. (So, we don't need to add additional --allow-empty as we do now).

I also think that the above thing can be a bit confusing and I would be happy to do more improvements or suggestions to implement it in a more user friendly way.

Show 14 quoted lines

> This is clear to me because '--fixup' makes a commit that is interpreted
> separately by the sequencer machinery, so any options that are given
> with it seem to indicate that they will alter how the sequencer
> interprets the resulting commit, which makes sense.
>
> Of course, it's all somewhat confusing because you have to keep track of
> which are options to 'git commit', and which are sequencer commands, but
> I like the direction that you're going in here.
>
> > Next,
> > To use only, `--fixup=<commit> --edit` to make the "amend!" commit.
>
> I don't think that this is as good a direction forward.
>

I agree, thanks.

Thanks and Regards, Charvi

Show 15 quoted lines

> > Also as discussed earlier[3] we are avoiding the use of additional
> > options like `git commit --amend=<commit>` inorder to avoid confusion
> > of doing similar things in different ways. So, I wonder which could be
> > the best way to proceed with or if any other way to implement "amend!"
> > commit ?
> >
> > Thanks and Regards,
> > Charvi
> >
> > [1] https://github.com/gitgitgadget/git/issues/259
> > [2] https://lore.kernel.org/git/20210108092345.2178-1-charvi077@gmail.com/
> > [3] https://lore.kernel.org/git/95cc6fb2-d1bc-11de-febe-c2b5c78a6850@gmail.com/
>
> Thanks,
> Taylor