git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Charvi Mendiratta <charvi077@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com,
	phillip.wood123@gmail.com
Subject: Re: [PATCH 0/6][Outreachy] commit: Implementation of "amend!" commit
Date: Tue, 23 Feb 2021 11:55:22 -0800	[thread overview]
Message-ID: <xmqqeeh61rv9.fsf@gitster.g> (raw)
In-Reply-To: <20210217072904.16257-1-charvi077@gmail.com> (Charvi Mendiratta's message of "Wed, 17 Feb 2021 12:59:06 +0530")

Charvi Mendiratta <charvi077@gmail.com> 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.




  parent reply	other threads:[~2021-02-23 19:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17  7:29 [PATCH 0/6][Outreachy] commit: Implementation of "amend!" commit Charvi Mendiratta
2021-02-17  7:37 ` [PATCH 1/6] sequencer: export subject_length() Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 2/6] commit: add amend suboption to --fixup to create amend! commit Charvi Mendiratta
2021-02-17 19:49     ` Junio C Hamano
2021-02-18 10:13       ` Charvi Mendiratta
2021-02-18 19:18         ` Junio C Hamano
2021-02-18 20:37           ` Junio C Hamano
2021-02-19  6:10             ` Charvi Mendiratta
2021-02-19  6:09           ` Charvi Mendiratta
2021-02-20  3:15             ` Junio C Hamano
2021-02-21  6:35               ` Charvi Mendiratta
2021-02-21  7:05                 ` Junio C Hamano
2021-02-21  9:20                   ` Charvi Mendiratta
2021-02-22 17:35                     ` Junio C Hamano
2021-02-23  6:05                       ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 3/6] commit: add a reword suboption to --fixup Charvi Mendiratta
2021-02-17 19:56     ` Junio C Hamano
2021-02-18 10:14       ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 4/6] t7500: add tests for --fixup[amend|reword] options Charvi Mendiratta
2021-02-17 19:59     ` Junio C Hamano
2021-02-18 10:15       ` Charvi Mendiratta
2021-02-18 19:26         ` Junio C Hamano
2021-02-19  6:10           ` Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 5/6] t3437: use --fixup with options to create amend! commit Charvi Mendiratta
2021-02-17  7:37   ` [PATCH 6/6] doc/git-commit: add documentation for fixup[amend|reword] options Charvi Mendiratta
2021-02-18 19:23     ` Junio C Hamano
2021-02-19  6:09       ` Charvi Mendiratta
2021-02-23 19:55 ` Junio C Hamano [this message]
2021-02-24  5:54   ` [PATCH 0/6][Outreachy] commit: Implementation of "amend!" commit Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 " Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 1/6] sequencer: export subject_length() Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 2/6] commit: add amend suboption to --fixup to create amend! commit Charvi Mendiratta
2021-02-25 21:00   ` Junio C Hamano
2021-02-26 10:38     ` Charvi Mendiratta
2021-02-26 19:32       ` Junio C Hamano
2021-02-27  4:56         ` Charvi Mendiratta
2021-02-25 10:08 ` [PATCH v2 3/6] commit: add a reword suboption to --fixup Charvi Mendiratta
2021-02-25 20:32   ` Junio C Hamano
2021-02-26 10:35     ` Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 4/6] t7500: add tests for --fixup=[amend|reword] options Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 5/6] t3437: use --fixup with options to create amend! commit Charvi Mendiratta
2021-02-25 10:09 ` [PATCH v2 6/6] doc/git-commit: add documentation for fixup=[amend|reword] options Charvi Mendiratta
2021-02-25 20:48   ` Junio C Hamano
2021-02-26 10:36     ` 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=xmqqeeh61rv9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=charvi077@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    /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).