From: Charvi Mendiratta <charvi077@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: How to implement the "amend!" commit ?
Date: Thu, 14 Jan 2021 13:36:07 +0530 [thread overview]
Message-ID: <CAPSFM5c=BT2S_32FrfFO7x1EONgaRE0C_TREhaYZVi8F=oj17g@mail.gmail.com> (raw)
In-Reply-To: <X/864HdPtf1km0xZ@nand.local>
Hi Taylor,
On Wed, 13 Jan 2021 at 23:54, Taylor Blau <me@ttaylorr.com> wrote:
>
> 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.
> - 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`.
> > 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.
> 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
> > 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
next prev parent reply other threads:[~2021-01-14 8:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPSFM5c2iqBn8_Dih2id7q6RRp0q=vfCSVUHDE5AOXZ8z3Ko9w@mail.gmail.com>
2021-01-13 1:15 ` How to implement the "amend!" commit ? Charvi Mendiratta
2021-01-13 18:24 ` Taylor Blau
2021-01-13 18:27 ` Taylor Blau
2021-01-14 8:06 ` Charvi Mendiratta [this message]
2021-01-14 10:39 ` Phillip Wood
2021-01-14 17:32 ` Taylor Blau
2021-01-15 10:42 ` Phillip Wood
2021-01-15 18:05 ` Martin Ågren
2021-01-14 20:32 ` Junio C Hamano
2021-01-15 10:29 ` Phillip Wood
2021-01-15 17:23 ` Junio C Hamano
2021-01-17 3:43 ` Charvi Mendiratta
2021-01-17 4:33 ` Junio C Hamano
2021-01-17 7:46 ` Charvi Mendiratta
2021-01-15 8:37 ` 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='CAPSFM5c=BT2S_32FrfFO7x1EONgaRE0C_TREhaYZVi8F=oj17g@mail.gmail.com' \
--to=charvi077@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.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).