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):
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).
Secondly,
As an alternative to above, we can use `--fixup=<commit> --amend` and
`--fixup=<commit> --reword`.
Next,
To use only, `--fixup=<commit> --edit` to make the "amend!" commit.
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/
From: Taylor Blau <hidden> Date: 2021-01-13 18:25:34
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
- 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.
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.
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.
From: Taylor Blau <hidden> Date: 2021-01-13 18:29:01
On Wed, Jan 13, 2021 at 01:24:32PM -0500, Taylor Blau wrote:
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'.
Oops. Ignore everything after the 'but...' until the next '...' below.
Thanks,
Taylor
Hi Taylor,
On Wed, 13 Jan 2021 at 23:54, Taylor Blau [off-list ref] wrote:
Hi Chavri,
On Wed, Jan 13, 2021 at 06:45:25AM +0530, Charvi Mendiratta wrote:
quoted
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`.
quoted
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'.
quoted
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.
quoted
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've taken the liberty of adding some comments about the backwards
compatibility of each option
On 13/01/2021 01:15, 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):
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).
This is the only option that is backwards compatible. `--fixup=:/<text>
` still works and can be used with the new syntax as
`--fixup=amend::/<text>`. Note that we intend to allow accept any prefix
of "amend" and "reword" so --fixup=a:<commit> would work.
Secondly,
As an alternative to above, we can use `--fixup=<commit> --amend` and
`--fixup=<commit> --reword`.
This is not backwards compatible. At the moment If you create a fixup
with `git commit --fixup=aaa` and then realize it should refer to commit
bbb instead you can fix it with `git commit --amend --fixup=bbb`. That
would no longer be possible. (You could still do `git commit --amend
-m'fixup! bbb'` which works with `git rebase --autosquash` but is not
very helpful when running `git log` or `git commit --amend -m"$(git log
-1 --format=%s bbb)" which is a pain to type.)
Next,
To use only, `--fixup=<commit> --edit` to make the "amend!" commit.
This is not backwards compatible. At the moment this combination of
options allows the user to add some comments to the fixup commit
message. To do that in the future they'd have to change the subject line
when editing the message.
Best Wishes
Phillip
From: Taylor Blau <hidden> Date: 2021-01-14 17:32:59
On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
quoted
Secondly, As an alternative to above, we can use `--fixup=<commit>
--amend` and `--fixup=<commit> --reword`.
This is not backwards compatible. At the moment If you create a fixup with
`git commit --fixup=aaa` and then realize it should refer to commit bbb
instead you can fix it with `git commit --amend --fixup=bbb`. That would no
longer be possible.
Too bad. I felt that this was the most ergonomic idea put forwards, but
I also thought that we died with '--amend --fixup=xxx'. Its current
behavior does make sense to me, but it's too bad that we can't use it
for this new purpose.
I suppose the first option (the '--fixup=reword:xxx' one really is the
only one that can be implemented while preserving backwards
compatibility, so I think we have no choice but to go with that one.)
Thanks,
Taylor
On Thu, 14 Jan 2021 at 16:09, Phillip Wood [off-list ref] wrote:
I've taken the liberty of adding some comments about the backwards
compatibility of each option
On 13/01/2021 01:15, Charvi Mendiratta wrote:
quoted
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):
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).
This is the only option that is backwards compatible. `--fixup=:/<text>
` still works and can be used with the new syntax as
`--fixup=amend::/<text>`. Note that we intend to allow accept any prefix
of "amend" and "reword" so --fixup=a:<commit> would work.
quoted
Secondly,
As an alternative to above, we can use `--fixup=<commit> --amend` and
`--fixup=<commit> --reword`.
This is not backwards compatible. At the moment If you create a fixup
with `git commit --fixup=aaa` and then realize it should refer to commit
bbb instead you can fix it with `git commit --amend --fixup=bbb`. That
would no longer be possible. (You could still do `git commit --amend
-m'fixup! bbb'` which works with `git rebase --autosquash` but is not
very helpful when running `git log` or `git commit --amend -m"$(git log
-1 --format=%s bbb)" which is a pain to type.)
I found above, "git commit --amend --fixup=bbb" as one of the hidden
features I had never used before. I also agree to go with first one and
working on the patch to apply it.
Thanks and Regards,
Charvi
quoted
Next,
To use only, `--fixup=<commit> --edit` to make the "amend!" commit.
This is not backwards compatible. At the moment this combination of
options allows the user to add some comments to the fixup commit
message. To do that in the future they'd have to change the subject line
when editing the message.
Best Wishes
Phillip
On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
quoted
quoted
Secondly, As an alternative to above, we can use `--fixup=<commit>
--amend` and `--fixup=<commit> --reword`.
This is not backwards compatible. At the moment If you create a fixup with
`git commit --fixup=aaa` and then realize it should refer to commit bbb
instead you can fix it with `git commit --amend --fixup=bbb`. That would no
longer be possible.
Too bad. I felt that this was the most ergonomic idea put forwards, but
I also thought that we died with '--amend --fixup=xxx'. Its current
behavior does make sense to me, but it's too bad that we can't use it
for this new purpose.
I guess we could decide to change the behavior but I'm not sure there is
a sufficiently compelling reason to do that. I agree the current
behavior makes sense but (based on no data at all) I'm not sure that it
is used very much. One thing I like about this option is that it is much
easier to create an alias to create a particular type of fixup, with
--fixup=amend:<commit> you have to use a shell function alias to do
that. The down side of re-purposing "--amend" is that it no longer
always rewrites HEAD which is potentially confusing.
I suppose the first option (the '--fixup=reword:xxx' one really is the
only one that can be implemented while preserving backwards
compatibility, so I think we have no choice but to go with that one.)
I agree, to me it feels a bit more cumbersome, but on the plus side I
think it is arguably clearer than re-purposing '--fixup=<commit>
--amend' and it is slightly less typing than specifying two options as well.
Thanks for your comments on this series
Best Wishes
Phillip
From: Martin Ågren <hidden> Date: 2021-01-15 18:05:58
On Fri, 15 Jan 2021 at 12:08, Phillip Wood [off-list ref] wrote:
On 14/01/2021 17:32, Taylor Blau wrote:
quoted
On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
quoted
quoted
Secondly, As an alternative to above, we can use `--fixup=<commit>
--amend` and `--fixup=<commit> --reword`.
This is not backwards compatible. At the moment If you create a fixup with
`git commit --fixup=aaa` and then realize it should refer to commit bbb
instead you can fix it with `git commit --amend --fixup=bbb`. That would no
longer be possible.
Too bad. I felt that this was the most ergonomic idea put forwards, but
I also thought that we died with '--amend --fixup=xxx'. Its current
behavior does make sense to me, but it's too bad that we can't use it
for this new purpose.
I guess we could decide to change the behavior but I'm not sure there is
a sufficiently compelling reason to do that. I agree the current
behavior makes sense but (based on no data at all) I'm not sure that it
is used very much. [...]
Data point: I've done this more than once to correct my choice of which
commit to fixup. I'd like to think I'm not very special, so I would
guess that I'm not the *only one* who has come up with that and found it
useful. As for being used "very much", no idea.
But regardless of that, it feels awkward to me to tie those two options
together. That feeling might well correlate with having found that
combo to be useful in the first place, though.
Martin