From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
Git List <git@vger.kernel.org>,
"Bradley M. Kuhn" <bkuhn@sfconservancy.org>,
Junio C Hamano <gitster@pobox.com>,
Brandon Casey <drafnel@gmail.com>,
Shourya Shukla <periperidip@gmail.com>,
Christian Couder <christian.couder@gmail.com>,
Rafael Silva <rafaeloliveira.cs@gmail.com>
Subject: Re: [PATCH v8 1/2] [GSOC] commit: add --trailer option
Date: Wed, 17 Mar 2021 09:08:26 +0100 [thread overview]
Message-ID: <87wnu6dwxx.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAOLTT8RyCvs8bbedPaRSo44o566Tk1MK9BeLx=-APnFsHJtejw@mail.gmail.com>
On Wed, Mar 17 2021, ZheNing Hu wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 于2021年3月16日周二 下午8:52写道:
>> > + if (run_command(&run_trailer))
>> > + strvec_clear(&run_trailer.args);
>>
>> This is git-commit, shouldn't we die() here instead of ignoring errors
>> in sub-processes?
>
> After thinking about it carefully, your opinion is more
> reasonable, because if the user uses the wrong `--trailer`
> and does not get the information he needs, I think he will
> have to use `--amend` to modify, and `die()` can exit
> this commit directly.
Yeah, we don't want to silently lose data.
>>
>> > + strvec_clear(&trailer_args);
>> > + }
>> > +
>> > /*
>> > * Reject an attempt to record a non-merge empty commit without
>> > * explicit --allow-empty. In the cherry-pick case, it may be
>> > @@ -1507,6 +1529,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>> > OPT_STRING(0, "fixup", &fixup_message, N_("commit"), N_("use autosquash formatted message to fixup specified commit")),
>> > OPT_STRING(0, "squash", &squash_message, N_("commit"), N_("use autosquash formatted message to squash specified commit")),
>> > OPT_BOOL(0, "reset-author", &renew_authorship, N_("the commit is authored by me now (used with -C/-c/--amend)")),
>> > + OPT_CALLBACK_F(0, "trailer", NULL, N_("trailer"), N_("trailer(s) to add"), PARSE_OPT_NONEG, opt_pass_trailer),
>> > OPT_BOOL('s', "signoff", &signoff, N_("add a Signed-off-by trailer")),
>>
>> Not required for this change, but perhaps a change here to N_() (if we
>> can get it to fit) + doc update saying that we prefer
>> --trailer="Signed-Off-By: to --signoff"? More on that later.
>>
>> > OPT_FILENAME('t', "template", &template_file, N_("use specified template file")),
>> > OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
>> > diff --git a/t/t7502-commit-porcelain.sh b/t/t7502-commit-porcelain.sh
>> > index 6396897cc818..0acf23799931 100755
>> > --- a/t/t7502-commit-porcelain.sh
>> > +++ b/t/t7502-commit-porcelain.sh
>> > @@ -154,6 +154,26 @@ test_expect_success 'sign off' '
>> >
>> > '
>> >
>> > +test_expect_success 'trailer' '
>> > + >file1 &&
>> > + git add file1 &&
>> > + git commit -s --trailer "Signed-off-by:C O Mitter1 <committer1@example.com>" \
>> > + --trailer "Helped-by:C O Mitter2 <committer2@example.com>" \
>> > + --trailer "Reported-by:C O Mitter3 <committer3@example.com>" \
>> > + --trailer "Mentored-by:C O Mitter4 <committer4@example.com>" \
>> > + -m "hello" &&
>> > + git cat-file commit HEAD >commit.msg &&
>> > + sed -e "1,7d" commit.msg >actual &&
>> > + cat >expected <<-\EOF &&
>> > + Signed-off-by: C O Mitter <committer@example.com>
>> > + Signed-off-by: C O Mitter1 <committer1@example.com>
>> > + Helped-by: C O Mitter2 <committer2@example.com>
>> > + Reported-by: C O Mitter3 <committer3@example.com>
>> > + Mentored-by: C O Mitter4 <committer4@example.com>
>> > + EOF
>> > + test_cmp expected actual
>> > +'
>> > +
>>
>> How does this interact with cases where the user has configured
>> "trailer.separators" to have a value that doesn't contain ":"? I
>> haven't tested, but my reading of git-interpret-trailers(1) is that if
>> you supplied "=" instead that case would just work:
>>
>> By default only : is recognized as a trailer separator, except that
>> = is always accepted on the command line for compatibility with
>> other git commands.
>>
> But interpret_trailers interface allow us use "=" instead of other separators.
>
> I did a simple test and modified the configuration "trailer.separators"
> and it still works. Now things are good here:
>
> $ git -c trailer.separators="@" commit --trailer="Signed-off-by=C O <email>"
>
> or
>
> $ git -c trailer.separators="@" commit --trailer="Signed-off-by@C O <email>"
>
> Both can work normally,
>
> --trailer="Signed-off-by@ C O <email>"
>
> will output in the commit message.
>
>> I don't know if that does the right thing in the presence of
>> --if-exists=add.
>>
>
> Yesterday, Christian Couder and I had already discussed this issue:
> Your idea is correct, I should not add "--if-exists = add", this will destroy
> the user's rights to configure by using `git -c trailer.if-exist`.
>
>> So it would be good to update these tests so you test:
>>
>> * For the --if-exists=add case at all, there's no tests for it
>> now. I.e. add some trailers manually to the commit (via -F or
>> whatever) and then see if they get added to, replacet etc.
>>
>> * Ditto but for the user having configured trailer.separators (see the
>> test_config helper for how to set config in a test). I.e. if it's "="
>> does adding trailers work, how about if it's "=" on the CLI but the
>> config/commit message has ";" instead of ":" or something?
>>
>
> As mentioned above, it works normally.
>
>> * Hrm, actually I think tweaking "-c trailer.ifexists" won't work at
>> all, since the CLI switch would override it. I honestly don't know,
>> but why not not supply it and keep the addIfDifferentNeighbor
>> default?
>>
>> If it's essential that seems like a good test / documentation
>> addition...
>>
>> * For the above -c ... case I can't think of a good way to deal with it
>> that doesn't involve pulling in git_trailer_config() into
>> git_commit_config(), but perhaps the least nasty way is to just set a
>> flag in git_commit_config() if we see a "trailer.ifexists" flag, and
>> if so don't provide "--if-exists=add", if there's no config (this
>> will include "git -c ... commit" we set provide "--if-exists=add" )
>> or as noted above, maybe we can skip the whole thing and use the
>> addIfDifferentNeighbor default.
>>
>
> Has been restored to the default settings.
To clarify: What I really mean is for all these things you've tested:
let's add those to the tests as part of the patch.
>> And, not needed for this patch but worth thinking about:
>>
>> * We pass through --trailer to git-interpret-trailers, what should we
>> do about the other options? Should git-commit eventually support
>> --trailer-where and pass it along as --where to
>> git-interpret-trailers, or is "git -c trailer.where=... commit" good
>> enough?
>>
> Logically speaking, `interpret_trailers` should be dedicated to `commit`
> or other sub-commands that require trailers.
>
> But I think that in the later stage, the parse_options of the `cmd_commit`
> can keep the unrecognized options, and then these choices can be directly
> passed to the `interpret_trailers` backend.
We have this interaction with e.g. range-diff and "log", it's often
surprising. You add an option to one command and it appears in the
other.
>> * It would be good to test for and document if that "-c trailer.*"
>> trick works (no reason it shouldn't). I.e. to add something like this
>> after what you have (along with tests, and check if it's even true):
>>
>
> I haven't tested them for the time being, but I will do it.
>
>> Only the `--trailer` argument to
>> linkgit:git-interpret-trailers[1] is supported. Other
>> pass-through switches may be added in the future, but currently
>> you'll need to pass arguments to
>> linkgit:git-interpret-trailers[1] along as config, e.g. `git -c
>> trailer.where=start commit [...] --trailer=[...]`.
>>
>
> I think this is worth writing in the documentation.
>
>> * We have a longer-term goal of having the .mailmap apply to trailers,
>> it would be nice if git-interpret-trailers had some fuzzy-matching to
>> check if the RHS of a trailer is a name/E-Mail pair, and if so did
>> stricter validation on it with the ident functions we use for fsck
>> etc. (that's copied & subtly different in several different places in
>> the codebase, unfortunately[1]).
>>
>
> I may not know much about fuzzy-matching, which may be worth studying later.
>
>> More thoughts:
>>
>> * Having written all the above I checked how --signoff is implemented.
>>
>> It seems to me to be a good idea to (at least for testing) convert
>> the --signoff trailer to your implementation. We have plenty of tests
>> for it, does migrating it over pass or fail those?
>>
> I don’t know how to migrating yet, it may take a long time.
> Even I think I can leave it as #leftoverbit later.
Sure, I mean (having looked at it) that at least for your own local
testing it would make sense to change it (even if just search-replacing
the --signoff in the test suite) to see if it behaves as you
expect. I.e. does the --trailer behavior mirror --signoff?
>> * I also agree with Junio that we shouldn't have a --fixed-by or
>> whatever and wouldn't add --signoff today, but it seems very useful
>> to me to have a shortcut like:
>>
>> --trailer "Signed-off-by"
>>
>> I.e. omitting the value, or:
>>
>> --trailer "Signed-off-by="
>>
>> Or some other thing we deem sufficiently useful/sane
>> syntax/unambiguous.n
>>
>> Then the value would be provided by fmt_name(WANT_COMMITTER_IDENT)
>> just as we do in append_signoff() now. I think a *very common* case
>> for this would be something like:
>>
>> git commit --amend -v --trailer "Reviewed-by"
>>
>> And it would be useful to help that along and not have to do:
>>
>> git commit --amend -v --trailer "Reviewed-by=$(git config user.name) <$(git config user.email)>"
>>
>> Or worse yet, manually typo your name/e-mail address, as I'm sure I
>> and many others will inevitably do when using this option...
>>
> I think this idea is very good and easy to implement.
> We only need to do a simple string match when we get the "trailer" string,
> If it can be completed, it can indeed bring great convenience to users.
>
>> 1. https://lore.kernel.org/git/87bld8ov9q.fsf@evledraar.gmail.com/
>
> Thanks, Ævar Arnfjörð Bjarmason!
And thanks for working on this.
next prev parent reply other threads:[~2021-03-17 8:09 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 7:16 [PATCH] [GSOC] commit: provides multiple common signatures ZheNing Hu via GitGitGadget
2021-03-11 15:03 ` Shourya Shukla
2021-03-12 11:41 ` ZheNing Hu
2021-03-11 17:28 ` Junio C Hamano
2021-03-12 12:01 ` ZheNing Hu
2021-03-12 13:22 ` ZheNing Hu
2021-03-12 15:54 ` [PATCH v2] [GSOC] commit: add trailer command ZheNing Hu via GitGitGadget
2021-03-14 4:19 ` Christian Couder
2021-03-14 7:09 ` ZheNing Hu
2021-03-14 22:45 ` Junio C Hamano
2021-03-14 13:02 ` [PATCH v3] [GSOC] commit: add --trailer option ZheNing Hu via GitGitGadget
2021-03-14 13:10 ` Rafael Silva
2021-03-14 14:13 ` ZheNing Hu
2021-03-14 15:58 ` [PATCH v4] " ZheNing Hu via GitGitGadget
2021-03-14 23:52 ` Junio C Hamano
2021-03-15 1:27 ` ZheNing Hu
2021-03-15 4:42 ` Junio C Hamano
2021-03-15 5:14 ` ZheNing Hu
2021-03-15 3:24 ` [PATCH v5] " ZheNing Hu via GitGitGadget
2021-03-15 5:33 ` Christian Couder
2021-03-15 5:41 ` Christian Couder
2021-03-15 5:46 ` ZheNing Hu
2021-03-15 6:35 ` [PATCH v6] " ZheNing Hu via GitGitGadget
2021-03-15 8:02 ` Christian Couder
2021-03-15 8:21 ` ZheNing Hu
2021-03-15 9:08 ` [PATCH v7] " ZheNing Hu via GitGitGadget
2021-03-15 10:00 ` Christian Couder
2021-03-15 10:14 ` Christian Couder
2021-03-15 11:32 ` ZheNing Hu
2021-03-16 5:37 ` Christian Couder
2021-03-16 8:35 ` ZheNing Hu
2021-03-15 13:07 ` [PATCH v8 0/2] " ZheNing Hu via GitGitGadget
2021-03-15 13:07 ` [PATCH v8 1/2] " ZheNing Hu via GitGitGadget
2021-03-16 12:52 ` Ævar Arnfjörð Bjarmason
2021-03-17 2:01 ` ZheNing Hu
2021-03-17 8:08 ` Ævar Arnfjörð Bjarmason [this message]
2021-03-17 13:54 ` ZheNing Hu
2021-03-15 13:07 ` [PATCH v8 2/2] interpret_trailers: for three options parse add warning ZheNing Hu via GitGitGadget
2021-03-16 5:53 ` Christian Couder
2021-03-16 9:11 ` ZheNing Hu
2021-03-16 10:39 ` [PATCH v9] [GSOC] commit: add --trailer option ZheNing Hu via GitGitGadget
2021-03-17 5:26 ` Shourya Shukla
2021-03-17 6:06 ` ZheNing Hu
2021-03-18 11:15 ` [PATCH v10 0/3] " ZheNing Hu via GitGitGadget
2021-03-18 11:15 ` [PATCH v10 1/3] " ZheNing Hu via GitGitGadget
2021-03-18 16:29 ` Đoàn Trần Công Danh
2021-03-19 7:56 ` ZheNing Hu
2021-03-18 11:15 ` [PATCH v10 2/3] interpret-trailers: add own-identity option ZheNing Hu via GitGitGadget
2021-03-18 16:45 ` Đoàn Trần Công Danh
2021-03-19 8:04 ` ZheNing Hu
2021-03-18 19:20 ` Junio C Hamano
2021-03-19 9:33 ` ZheNing Hu
2021-03-19 15:36 ` Junio C Hamano
2021-03-20 2:54 ` ZheNing Hu
2021-03-20 5:06 ` Jeff King
2021-03-20 5:50 ` Junio C Hamano
2021-03-20 6:16 ` ZheNing Hu
2021-03-20 6:38 ` ZheNing Hu
2021-03-20 6:53 ` Junio C Hamano
2021-03-20 8:43 ` ZheNing Hu
2021-03-18 11:15 ` [PATCH v10 3/3] commit: " ZheNing Hu via GitGitGadget
2021-03-18 13:47 ` [PATCH v10 0/3] [GSOC] commit: add --trailer option Christian Couder
2021-03-18 15:27 ` ZheNing Hu
2021-03-19 12:05 ` [PATCH v11] " ZheNing Hu via GitGitGadget
2021-03-19 17:48 ` Junio C Hamano
2021-03-20 13:41 ` [PATCH v12] " ZheNing Hu via GitGitGadget
2021-03-22 4:24 ` [PATCH v13] " ZheNing Hu via GitGitGadget
2021-03-22 7:43 ` Christian Couder
2021-03-22 10:23 ` ZheNing Hu
2021-03-22 21:34 ` Christian Couder
2021-03-23 6:11 ` ZheNing Hu
2021-03-23 6:19 ` Junio C Hamano
2021-03-23 7:57 ` Christian Couder
2021-03-23 17:11 ` Junio C Hamano
2021-03-24 5:21 ` ZheNing Hu
2021-03-23 10:35 ` ZheNing Hu
2021-03-23 12:41 ` Christian Couder
2021-03-23 17:12 ` Junio C Hamano
2021-03-24 5:25 ` ZheNing Hu
2021-03-22 21:55 ` Christian Couder
2021-03-23 6:29 ` ZheNing Hu
2021-03-23 13:55 ` [PATCH v14] " ZheNing Hu via GitGitGadget
2021-03-15 4:38 ` [PATCH v4] " Junio C Hamano
2021-03-15 5:11 ` ZheNing Hu
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=87wnu6dwxx.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=adlternative@gmail.com \
--cc=bkuhn@sfconservancy.org \
--cc=christian.couder@gmail.com \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=periperidip@gmail.com \
--cc=rafaeloliveira.cs@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).