From: Junio C Hamano <gitster@pobox.com>
To: "Łukasz Gryglicki" <lukaszgryglicki@o2.pl>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] area: git-merge: add --signoff flag to git-merge
Date: Mon, 03 Jul 2017 10:57:10 -0700 [thread overview]
Message-ID: <xmqqwp7pl7yh.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <0102015d07e215ae-a711670e-8315-40b9-90cf-f95075525622-000000@eu-west-1.amazonses.com> ("Łukasz Gryglicki"'s message of "Mon, 3 Jul 2017 09:57:23 +0000")
Łukasz Gryglicki <lukaszgryglicki@o2.pl> writes:
> Subject: Re: [PATCH] area: git-merge: add --signoff flag to git-merge
s/area: //;
> Added --signoff flag to `git-merge` command, added test coverage,
> updated documentation.
That can be seen from the title and the patch text. While it is not
wrong to list what you did, that shouldn't be the only thing the log
records. Explain the problem the patch attempts to fix, why it is a
problem, and then give orders to the code to "be like so".
[PATCH] git-merge: honor --signoff flag
The "Signed-off-by:" line is a social convention to certify
that you are legally allowed to do so when you are giving
changes to or recording changes for the project.
The "git commit" command has a handy option "--signoff" to
add it under your name, because committing is the primary
way for you to record your changes (which may later be sent
to the project in a patch form).
On the other hand, the "git merge" command does not. [You
make an argument to justify why merge commits also should
have signoffs here].
Teach "git merge" to honor "--signoff" just like "git commit"
does.
or something like that. It is a norm for a new feature to have
documentation and test, so it is of lessor importance to say "Add
tests and document the new feature" (on the other hand, those who do
not test and document need to justify their omission).
Alternatively, if the problem is so obvious that it does not need to
be explained, the solution often does not need more explanation than
the patch title.
I this case, I think the "problem" is not that obvious; the need for
signing off a merge commit deserves explanation in the log message.
> Signed-off-by: lukaszgryglicki <lukaszgryglicki@o2.pl>
> ---
"Signed-off-by: Łukasz Gryglicki <lukaszgryglicki@o2.pl>", like you wrote
on your "From:" e-mail header.
> Documentation/git-merge.txt | 8 ++++++
> builtin/merge.c | 4 +++
> t/t9904-git-merge-signoff.sh | 60 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 72 insertions(+)
> create mode 100755 t/t9904-git-merge-signoff.sh
>
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index 04fdd8cf086db..6b308ab6d0b52 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -64,6 +64,14 @@ OPTIONS
> -------
> include::merge-options.txt[]
>
> +--signoff::
> + Add Signed-off-by line by the committer at the end of the commit
> + log message. The meaning of a signoff depends on the project,
> + but it typically certifies that committer has
> + the rights to submit this work under the same license and
> + agrees to a Developer Certificate of Origin
> + (see http://developercertificate.org/ for more information).
> +
Good description.
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 900bafdb45d0b..cb09f4138136b 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -70,6 +70,7 @@ static int continue_current_merge;
> static int allow_unrelated_histories;
> static int show_progress = -1;
> static int default_to_upstream = 1;
> +static int signoff;
> static const char *sign_commit;
>
> static struct strategy all_strategy[] = {
> @@ -233,6 +234,7 @@ static struct option builtin_merge_options[] = {
> { OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key-id"),
> N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> OPT_BOOL(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
> + OPT_BOOL(0, "signoff", &signoff, N_("add Signed-off-by:")),
> OPT_END()
> };
>
> @@ -775,6 +777,8 @@ static void prepare_to_commit(struct commit_list *remoteheads)
> strbuf_stripspace(&msg, 0 < option_edit);
> if (!msg.len)
> abort_commit(remoteheads, _("Empty commit message."));
> + if (signoff)
> + append_signoff(&msg, ignore_non_trailer(msg.buf, msg.len), 0);
I think this is a wrong place to do this, because
(1) it is too late to allow "prepare-commit-msg" to futz with it.
(2) it is too late to allow the end user to further edit it.
A better place probably is before merge_editor_comment is added to
the msg strbuf in the same function, but I didn't think it through.
> diff --git a/t/t9904-git-merge-signoff.sh b/t/t9904-git-merge-signoff.sh
> new file mode 100755
> index 0000000000000..eed15b9a85371
> --- /dev/null
> +++ b/t/t9904-git-merge-signoff.sh
Do we need a new script? I think t7608 is about the messages in
the merge commit.
> +# A simple files to commit
> +cat >file1 <<EOF
> +1
> +EOF
> +
> +cat >file2 <<EOF
> +2
> +EOF
> +
> +cat >file3 <<EOF
> +3
> +EOF
>
> +
> +# Expected commit message after merge --signoff
> +cat >expected-signed <<EOF
> +Merge branch 'master' into other-branch
> +
> +Signed-off-by: $(git var GIT_COMMITTER_IDENT | sed -e "s/>.*/>/")
> +EOF
> +
> +# Expected commit message after merge without --signoff (or with --no-signoff)
> +cat >expected-unsigned <<EOF
> +Merge branch 'master' into other-branch
> +EOF
> +
All of the above should be done inside the first set-up test so that
they can be protected from errors.
> +
> +# We configure an alias to do the merge --signoff so that
> +# on the next subtest we can show that --no-signoff overrides the alias
Do we even need to risk these tests broken by an unrelated breakage
to the alias mechanism? Wouldn't testing
git merge --signoff --no-signoff ...
directly sufficient? The alias test may be a good thing to have _in
addition to_ such a basic test, though.
> +test_expect_success 'merge --signoff adds a sign-off line' '
> + git commit --allow-empty -m "Initial empty commit" &&
> + git checkout -b other-branch &&
> + git add file1 && git commit -m other-branch &&
> + git checkout master &&
> + git add file2 && git commit -m master-branch &&
> + git checkout other-branch &&
> + git config alias.msob "merge --signoff --no-edit" &&
Strange indentation.
> + git msob master &&
> + git cat-file commit HEAD | sed -e "1,/^\$/d" > actual &&
Style: no space between redirection and target.
> + test_cmp expected-signed actual
> +'
> +
> +test_expect_success 'master --no-signoff does not add a sign-off line' '
> + git checkout master &&
> + git add file3 && git commit -m master-branch-2 &&
> + git checkout other-branch &&
> + git msob --no-signoff master &&
> + git cat-file commit HEAD | sed -e "1,/^\$/d" > actual &&
> + test_cmp expected-unsigned actual
> +'
> +
> +test_done
Other than the above issues, looks like a very well done patch for
somebody who is posting a patch for the first time here. Welcome to
Git development community.
next prev parent reply other threads:[~2017-07-03 17:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-03 9:57 [PATCH] area: git-merge: add --signoff flag to git-merge Łukasz Gryglicki
2017-07-03 17:57 ` Junio C Hamano [this message]
2017-07-04 6:20 ` [PATCH v2] add --signoff flag to `git-merge` command Łukasz Gryglicki
2017-07-04 8:33 ` Ævar Arnfjörð Bjarmason
2017-07-04 17:42 ` Junio C Hamano
2017-07-04 9:33 ` [PATCH v3] merge: add a --signoff flag Łukasz Gryglicki
2017-07-24 6:14 ` lukaszgryglicki
2017-07-24 7:02 ` Junio C Hamano
2017-07-24 20:42 ` Junio C Hamano
2017-07-25 5:00 ` lukaszgryglicki
2017-07-25 5:10 ` Stefan Beller
2017-07-25 11:28 ` lukaszgryglicki
2017-07-25 18:41 ` Junio C Hamano
[not found] ` <7A9ED766-4A25-4F34-8E02-3DFCE1D63ADF@o2.pl>
2017-07-26 7:34 ` Junio C Hamano
2017-07-26 7:39 ` [PATCH v4] " Łukasz Gryglicki
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=xmqqwp7pl7yh.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=lukaszgryglicki@o2.pl \
/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).