[0/6,Outreachy] commit: Implementation of "amend!" commit

Message

Charvi Mendiratta Feb. 17, 2021, 7:29 a.m. UTC

This patch series teaches `git commit --fixup` to create "amend!" commit
as an alternative that works with `git rebase --autosquash`. It allows to
fixup both the content and the commit message of the specified commit.
Here we add two suboptions to the `--fixup`, first `amend` suboption that
creates an "amend!" commit. It takes the staged changes and also allows to
edit the commit message of the commit we are fixing.
Example usuage:
git commit --fixup=amend:<commit>

Secondly, `reword` suboption that creates an empty "amend!" commit i.e it
ignores the staged changes and only allows to reword/edit the commit message
of the commit we are fixing.
Example usuage:
git commit --fixup=reword:<commit>

** This work is rebased on the top of cm/rebase-i-updates.

Link to the related discussions:
https://lore.kernel.org/git/[e-mail]/

Charvi Mendiratta (6):
  sequencer: export subject_length()
  commit: add amend suboption to --fixup to create amend! commit
  commit: add a reword suboption to --fixup
  t7500: add tests for --fixup[amend|reword] options
  t3437: use --fixup with options to create amend! commit
  doc/git-commit: add documentation for fixup[amend|reword] options

 Documentation/git-commit.txt              |  39 +++++--
 Documentation/git-rebase.txt              |  21 ++--
 builtin/commit.c                          |  97 ++++++++++++++++--
 commit.c                                  |  14 +++
 commit.h                                  |   3 +
 sequencer.c                               |  14 ---
 t/t3437-rebase-fixup-options.sh           |  30 +-----
 t/t7500-commit-template-squash-signoff.sh | 118 ++++++++++++++++++++++
 8 files changed, 271 insertions(+), 65 deletions(-)

--
2.29.0.rc1

Comments

Junio C Hamano Feb. 23, 2021, 7:55 p.m. UTC | #1

Charvi Mendiratta <[e-mail]> writes:

> This patch series teaches `git commit --fixup` to create "amend!" commit
> as an alternative that works with `git rebase --autosquash`. It allows to
> fixup both the content and the commit message of the specified commit.
> Here we add two suboptions to the `--fixup`, first `amend` suboption that
> creates an "amend!" commit. It takes the staged changes and also allows to
> edit the commit message of the commit we are fixing.
> Example usuage:
> git commit --fixup=amend:<commit>
>
> Secondly, `reword` suboption that creates an empty "amend!" commit i.e it
> ignores the staged changes and only allows to reword/edit the commit message
> of the commit we are fixing.
> Example usuage:
> git commit --fixup=reword:<commit>

We used to have only --fixup that was meant to squeeze in minor
corrections to the contents recorded, and it kept the log message
of the original commit intact.

Now we have two other ways, --fixup=reword that is meant to correct
only the log message while keeping the contents intact from the
original, and --fixup=amend that is meant to allow users to do both.
They are nice additions to our toolbox.

While trying to use the --fixup=amend myself to "touch up" somebody
else's work today, another thing that we did not discuss so far came
to my mind (sorry, if this was discussed and resolved in your
previous discussions with other reviewers).  What should we do to
the authorship?

For the original --fixup, it is reasonably obvious that the original
authorship should be kept, as the intended use case is to make a
small tweak that does not change the intention of the commit in any
way (and that is why the log message from the original is kept), and
with --fixup=reword, it would probably be the same (the contents
were written by the original author alone, and the person fixing-up
is not changing only the log message).  So these two have a
reasonably good default model for the authorship information for the
final outcome: the original authorship should be kept (of course,
the user can easily take over the authorship later with "git commit
--amend --reset-author" perhaps run as part of "rebase -i", if the
contribution is significant enough to deserve the transfer of the
authorship).

But I am not sure what the default behaviour for the authorship when
--fixup=amend:<commit> is used to update somebody else's commit.  I
think it is OK to leave it to whatever the code happens to do right
now (simply because I have no strong reason to vote for either way
between keeping the original and letting the amending user take it
over), but I think it should be documented what happens in each
case.

Thanks.

Charvi Mendiratta Feb. 24, 2021, 5:54 a.m. UTC | #2

On Wed, 24 Feb 2021 at 01:25, Junio C Hamano <[e-mail]> wrote:
>
[...]
> We used to have only --fixup that was meant to squeeze in minor
> corrections to the contents recorded, and it kept the log message
> of the original commit intact.
>
> Now we have two other ways, --fixup=reword that is meant to correct
> only the log message while keeping the contents intact from the
> original, and --fixup=amend that is meant to allow users to do both.
> They are nice additions to our toolbox.
>
> While trying to use the --fixup=amend myself to "touch up" somebody
> else's work today, another thing that we did not discuss so far came
> to my mind (sorry, if this was discussed and resolved in your
> previous discussions with other reviewers).  What should we do to
> the authorship?
>

Yes, for the authorship similar to `--fixup`, when used with suboptions
`amend` or `reword`, it keeps the original authorship.

> For the original --fixup, it is reasonably obvious that the original
> authorship should be kept, as the intended use case is to make a
> small tweak that does not change the intention of the commit in any
> way (and that is why the log message from the original is kept), and
> with --fixup=reword, it would probably be the same (the contents
> were written by the original author alone, and the person fixing-up
> is not changing only the log message).  So these two have a
> reasonably good default model for the authorship information for the
> final outcome: the original authorship should be kept (of course,
> the user can easily take over the authorship later with "git commit
> --amend --reset-author" perhaps run as part of "rebase -i", if the
> contribution is significant enough to deserve the transfer of the
> authorship).
>
> But I am not sure what the default behaviour for the authorship when
> --fixup=amend:<commit> is used to update somebody else's commit.  I
> think it is OK to leave it to whatever the code happens to do right
> now (simply because I have no strong reason to vote for either way
> between keeping the original and letting the amending user take it
> over), but I think it should be documented what happens in each
> case.
>

Okay, I agree. We have included in the tests where we check both the
resulting commit message and the author details  but yes I will document
it as well.

Thanks and Regards,
Charvi