git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* How to implement the "amend!" commit ?
       [not found] <CAPSFM5c2iqBn8_Dih2id7q6RRp0q=vfCSVUHDE5AOXZ8z3Ko9w@mail.gmail.com>
@ 2021-01-13  1:15 ` Charvi Mendiratta
  2021-01-13 18:24   ` Taylor Blau
  2021-01-14 10:39   ` Phillip Wood
  0 siblings, 2 replies; 15+ messages in thread
From: Charvi Mendiratta @ 2021-01-13  1:15 UTC (permalink / raw)
  To: git; +Cc: Christian Couder, Phillip Wood

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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  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
  2021-01-14 10:39   ` Phillip Wood
  1 sibling, 2 replies; 15+ messages in thread
From: Taylor Blau @ 2021-01-13 18:24 UTC (permalink / raw)
  To: Charvi Mendiratta; +Cc: git, Christian Couder, Phillip Wood

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.

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-13 18:24   ` Taylor Blau
@ 2021-01-13 18:27     ` Taylor Blau
  2021-01-14  8:06     ` Charvi Mendiratta
  1 sibling, 0 replies; 15+ messages in thread
From: Taylor Blau @ 2021-01-13 18:27 UTC (permalink / raw)
  To: Taylor Blau; +Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-13 18:24   ` Taylor Blau
  2021-01-13 18:27     ` Taylor Blau
@ 2021-01-14  8:06     ` Charvi Mendiratta
  1 sibling, 0 replies; 15+ messages in thread
From: Charvi Mendiratta @ 2021-01-14  8:06 UTC (permalink / raw)
  To: Taylor Blau; +Cc: git, Christian Couder, Phillip Wood

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-13  1:15 ` How to implement the "amend!" commit ? Charvi Mendiratta
  2021-01-13 18:24   ` Taylor Blau
@ 2021-01-14 10:39   ` Phillip Wood
  2021-01-14 17:32     ` Taylor Blau
                       ` (2 more replies)
  1 sibling, 3 replies; 15+ messages in thread
From: Phillip Wood @ 2021-01-14 10:39 UTC (permalink / raw)
  To: Charvi Mendiratta, git; +Cc: Christian Couder, Phillip Wood, Taylor Blau

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

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-14 10:39   ` Phillip Wood
@ 2021-01-14 17:32     ` Taylor Blau
  2021-01-15 10:42       ` Phillip Wood
  2021-01-14 20:32     ` Junio C Hamano
  2021-01-15  8:37     ` Charvi Mendiratta
  2 siblings, 1 reply; 15+ messages in thread
From: Taylor Blau @ 2021-01-14 17:32 UTC (permalink / raw)
  To: Phillip Wood; +Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood

On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
> > 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-14 10:39   ` Phillip Wood
  2021-01-14 17:32     ` Taylor Blau
@ 2021-01-14 20:32     ` Junio C Hamano
  2021-01-15 10:29       ` Phillip Wood
  2021-01-17  3:43       ` Charvi Mendiratta
  2021-01-15  8:37     ` Charvi Mendiratta
  2 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-01-14 20:32 UTC (permalink / raw)
  To: Phillip Wood
  Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood, Taylor Blau

Phillip Wood <phillip.wood123@gmail.com> writes:

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

Do you mean both "--fixup=:/<text>" and "--fixup=amend::/<text>"
work and do the same thing?  If so, that is good.

> Note that we intend to allow
> accept any prefix of "amend" and "reword" so --fixup=a:<commit> would
> work.

"a" and "r" may happen to be unique but we would not want to be
limited to these two forever---future developers are allowed to
invent other clever variants.  So let's say "accept unique prefix as
abbreviation for these operating mode words like 'amend' and 'reword'"


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-14 10:39   ` Phillip Wood
  2021-01-14 17:32     ` Taylor Blau
  2021-01-14 20:32     ` Junio C Hamano
@ 2021-01-15  8:37     ` Charvi Mendiratta
  2 siblings, 0 replies; 15+ messages in thread
From: Charvi Mendiratta @ 2021-01-15  8:37 UTC (permalink / raw)
  To: Phillip Wood; +Cc: git, Christian Couder, Phillip Wood, Taylor Blau

On Thu, 14 Jan 2021 at 16:09, Phillip Wood <phillip.wood123@gmail.com> 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:
> > 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.)

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

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  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
  1 sibling, 1 reply; 15+ messages in thread
From: Phillip Wood @ 2021-01-15 10:29 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood, Taylor Blau

Hi Junio

On 14/01/2021 20:32, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> 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>`.
> Do you mean both "--fixup=:/<text>" and "--fixup=amend::/<text>"
> work and do the same thing?  If so, that is good.

"--fixup=:/<text>" will work as it does now and "--fixup=amend::/<text>" 
will create an amend! commit.

>> Note that we intend to allow
>> accept any prefix of "amend" and "reword" so --fixup=a:<commit> would
>> work.
> 
> "a" and "r" may happen to be unique but we would not want to be
> limited to these two forever---future developers are allowed to
> invent other clever variants.  So let's say "accept unique prefix as
> abbreviation for these operating mode words like 'amend' and 'reword'"

Sure - that's actually what I meant but I wasn't very clear

Do you think we want to support "--fixup=squash:<commit>" so there is a 
uniform way for creating all flavors or is that just going to be 
confusing when we have "--squash=<commit>" already?

Best Wishes

Phillip

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-14 17:32     ` Taylor Blau
@ 2021-01-15 10:42       ` Phillip Wood
  2021-01-15 18:05         ` Martin Ågren
  0 siblings, 1 reply; 15+ messages in thread
From: Phillip Wood @ 2021-01-15 10:42 UTC (permalink / raw)
  To: Taylor Blau; +Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood

Hi Taylor

On 14/01/2021 17:32, Taylor Blau wrote:
> On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
>>> 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

> Thanks,
> Taylor
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-15 10:29       ` Phillip Wood
@ 2021-01-15 17:23         ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-01-15 17:23 UTC (permalink / raw)
  To: Phillip Wood
  Cc: Charvi Mendiratta, git, Christian Couder, Phillip Wood, Taylor Blau

Phillip Wood <phillip.wood123@gmail.com> writes:

> "--fixup=:/<text>" will work as it does now and
> "--fixup=amend::/<text>" will create an amend! commit.

OK.  That sounds good.

Thanks.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-15 10:42       ` Phillip Wood
@ 2021-01-15 18:05         ` Martin Ågren
  0 siblings, 0 replies; 15+ messages in thread
From: Martin Ågren @ 2021-01-15 18:05 UTC (permalink / raw)
  To: Phillip Wood; +Cc: Taylor Blau, Charvi Mendiratta, git, Christian Couder

On Fri, 15 Jan 2021 at 12:08, Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> On 14/01/2021 17:32, Taylor Blau wrote:
> > On Thu, Jan 14, 2021 at 10:39:50AM +0000, Phillip Wood wrote:
> >>> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-14 20:32     ` Junio C Hamano
  2021-01-15 10:29       ` Phillip Wood
@ 2021-01-17  3:43       ` Charvi Mendiratta
  2021-01-17  4:33         ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Charvi Mendiratta @ 2021-01-17  3:43 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Phillip Wood, git, Christian Couder, Phillip Wood, Taylor Blau

Hi Junio and Phillip,

On Fri, 15 Jan 2021 at 02:02, Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
[...]
>
> > Note that we intend to allow
> > accept any prefix of "amend" and "reword" so --fixup=a:<commit> would
> > work.
>
> "a" and "r" may happen to be unique but we would not want to be
> limited to these two forever---future developers are allowed to
> invent other clever variants.  So let's say "accept unique prefix as
> abbreviation for these operating mode words like 'amend' and 'reword'"
>

Earlier, I thought to implement the UI of amend! commit as :
"git commit --fixup=a/amend:<commit>"

So users can either use 'a' as abbreviation or 'amend'. But I want to once
confirm if I got this right ? As I am doubtful about, what does allowing to
accept any prefix of "amend" and "reword" means ?

Thanks and Regards,
Charvi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-17  3:43       ` Charvi Mendiratta
@ 2021-01-17  4:33         ` Junio C Hamano
  2021-01-17  7:46           ` Charvi Mendiratta
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2021-01-17  4:33 UTC (permalink / raw)
  To: Charvi Mendiratta
  Cc: Phillip Wood, git, Christian Couder, Phillip Wood, Taylor Blau

Charvi Mendiratta <charvi077@gmail.com> writes:

> Earlier, I thought to implement the UI of amend! commit as :
> "git commit --fixup=a/amend:<commit>"
>
> So users can either use 'a' as abbreviation or 'amend'. But I want to once
> confirm if I got this right ? As I am doubtful about, what does allowing to
> accept any prefix of "amend" and "reword" means ?

It means that all of these do the same thing ...

	git commit --fixup=amend:<commit>
	git commit --fixup=amen:<commit>
	git commit --fixup=ame:<commit>
	git commit --fixup=am:<commit>
	git commit --fixup=a:<commit>

... until somebody more brilliant than either of us comes along and
invents another operation that sits next to 'amend' and 'reword',
say, 'annoy'.  At that point,

	git commit --fixup=a:<commit>

no longer uniquely identifies a choice among three ('amend',
'annoy', or 'reword') and you'd give an error message, but

	git commit --fixup=am:<commit>

will keep working as an abbreviation for "amend".

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: How to implement the "amend!" commit ?
  2021-01-17  4:33         ` Junio C Hamano
@ 2021-01-17  7:46           ` Charvi Mendiratta
  0 siblings, 0 replies; 15+ messages in thread
From: Charvi Mendiratta @ 2021-01-17  7:46 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Phillip Wood, git, Christian Couder, Phillip Wood, Taylor Blau

Hi Junio,

On Sun, 17 Jan 2021 at 10:03, Junio C Hamano <gitster@pobox.com> wrote:
>
> Charvi Mendiratta <charvi077@gmail.com> writes:
>
> > Earlier, I thought to implement the UI of amend! commit as :
> > "git commit --fixup=a/amend:<commit>"
> >
> > So users can either use 'a' as abbreviation or 'amend'. But I want to once
> > confirm if I got this right ? As I am doubtful about, what does allowing to
> > accept any prefix of "amend" and "reword" means ?
>
> It means that all of these do the same thing ...
>
>         git commit --fixup=amend:<commit>
>         git commit --fixup=amen:<commit>
>         git commit --fixup=ame:<commit>
>         git commit --fixup=am:<commit>
>         git commit --fixup=a:<commit>
>
> ... until somebody more brilliant than either of us comes along and
> invents another operation that sits next to 'amend' and 'reword',
> say, 'annoy'.  At that point,
>
>         git commit --fixup=a:<commit>
>
> no longer uniquely identifies a choice among three ('amend',
> 'annoy', or 'reword') and you'd give an error message, but
>
>         git commit --fixup=am:<commit>
>
> will keep working as an abbreviation for "amend".

Thanks for explaining, now I can relate with the previous discussions and
will look around for the implementation in the above way. I think may be we
can do this while parsing the options and checking for the list of prefixes,
I am not sure but will look into it.

Thanks and Regards,
Charvi

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-01-17  8:00 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git