contrib/subtree: Add -S/-gpg-sign#1928
contrib/subtree: Add -S/-gpg-sign#1928pweiskircher wants to merge 2 commits intogitgitgadget:masterfrom
Conversation
Welcome to GitGitGadgetHi @pweiskircher, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There are issues in commit 1f46176: |
|
There are issues in commit c8f4a6d: |
c8f4a6d to
c12243d
Compare
|
There are issues in commit c12243d: |
c12243d to
118ab05
Compare
|
There are issues in commit 118ab05: |
118ab05 to
cd05da4
Compare
|
There are issues in commit cd05da4: |
cd05da4 to
45ae2c3
Compare
|
@derrickstolee @dscho Hi! I've seen you give out some |
|
/allow |
|
User pweiskircher is now allowed to use GitGitGadget. WARNING: pweiskircher has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use. |
|
/preview |
|
Preview email sent as pull.1928.git.1748882171.gitgitgadget@gmail.com |
|
/submit |
|
Submitted as pull.1928.git.1748882439.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This patch series was integrated into seen via git@5e13850. |
|
This branch is now known as |
|
This patch series was integrated into seen via git@74f707e. |
| @@ -115,7 +115,7 @@ main () { | |||
| then | |||
There was a problem hiding this comment.
On the Git mailing list, "D. Ben Knoble" wrote (reply to this):
On Mon, Jun 2, 2025 at 12:41 PM Patrik Weiskircher via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Patrik Weiskircher <patrik@pspdfkit.com>
>
> -S/--gpg-sign requires an optional parameter. Optional parameter
> handling only works unambiguous with git rev-parse --parseopt when using
> the --stuck-long option.
Here we mention "-S", but that flag isn't implemented yet, right?
Perhaps something like:
Optional parameter handling only works unambiguous with git rev-parse
--parseopt when using the --stuck-long option. To prepare for future commits
which add flags with optional parameters, parse with --stuck-long.
>
> Signed-off-by: Patrik Weiskircher <patrik@pspdfkit.com>
> ---
> contrib/subtree/git-subtree.sh | 34 +++++++++++++---------------------
> 1 file changed, 13 insertions(+), 21 deletions(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index 15ae86db1b27..60b2431b8bba 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -115,7 +115,7 @@ main () {
> then
> set -- -h
> fi
> - set_args="$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
> + set_args="$(echo "$OPTS_SPEC" | git rev-parse --parseopt --stuck-long -- "$@" || echo exit $?)"
> eval "$set_args"
> . git-sh-setup
> require_work_tree
> @@ -131,9 +131,6 @@ main () {
> opt="$1"
> shift
> case "$opt" in
> - --annotate|-b|-P|-m|--onto)
> - shift
> - ;;
> --rejoin)
> arg_split_rejoin=1
> ;;
> @@ -177,42 +174,37 @@ main () {
> shift
>
> case "$opt" in
> - -q)
> + --quiet)
> arg_quiet=1
> ;;
> - -d)
> + --debug)
> arg_debug=1
> ;;
> - --annotate)
> + --annotate=*)
> test -n "$allow_split" || die_incompatible_opt "$opt" "$arg_command"
> - arg_split_annotate="$1"
> - shift
> + arg_split_annotate="${opt#*=}"
> ;;
> --no-annotate)
> test -n "$allow_split" || die_incompatible_opt "$opt" "$arg_command"
> arg_split_annotate=
> ;;
> - -b)
> + --branch=*)
> test -n "$allow_split" || die_incompatible_opt "$opt" "$arg_command"
> - arg_split_branch="$1"
> - shift
> + arg_split_branch="${opt#*=}"
> ;;
> - -P)
> - arg_prefix="${1%/}"
> - shift
> + --prefix=*)
> + arg_prefix="${opt#*=}"
> ;;
> - -m)
> + --message=*)
> test -n "$allow_addmerge" || die_incompatible_opt "$opt" "$arg_command"
> - arg_addmerge_message="$1"
> - shift
> + arg_addmerge_message="${opt#*=}"
> ;;
> --no-prefix)
> arg_prefix=
> ;;
> - --onto)
> + --onto=*)
> test -n "$allow_split" || die_incompatible_opt "$opt" "$arg_command"
> - arg_split_onto="$1"
> - shift
> + arg_split_onto="${opt#*=}"
> ;;
> --no-onto)
> test -n "$allow_split" || die_incompatible_opt "$opt" "$arg_command"
> --
> gitgitgadget
>
>
--
D. Ben KnobleThere was a problem hiding this comment.
On the Git mailing list, Patrik Weiskircher wrote (reply to this):
On Tue, Jun 3, 2025 at 4:42 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
>
> On Mon, Jun 2, 2025 at 12:41 PM Patrik Weiskircher via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: Patrik Weiskircher <patrik@pspdfkit.com>
> >
> > -S/--gpg-sign requires an optional parameter. Optional parameter
> > handling only works unambiguous with git rev-parse --parseopt when using
> > the --stuck-long option.
>
> Here we mention "-S", but that flag isn't implemented yet, right?
>
> Perhaps something like:
>
> Optional parameter handling only works unambiguous with git rev-parse
> --parseopt when using the --stuck-long option. To prepare for future commits
> which add flags with optional parameters, parse with --stuck-long.
>
Makes sense! Changing that. What is a good policy to resubmit
something? Should I wait longer? Sorry, very new here!There was a problem hiding this comment.
On the Git mailing list, "Kristoffer Haugsbakk" wrote (reply to this):
On Wed, Jun 4, 2025, at 15:56, Patrik Weiskircher wrote:
>>
>> Here we mention "-S", but that flag isn't implemented yet, right?
>>
>> Perhaps something like:
>>
>> Optional parameter handling only works unambiguous with git rev-parse
>> --parseopt when using the --stuck-long option. To prepare for future commits
>> which add flags with optional parameters, parse with --stuck-long.
>>
>
> Makes sense! Changing that. What is a good policy to resubmit
> something? Should I wait longer? Sorry, very new here!
• Force-push your branch to gitgitgadget
• Edit the PR description with something like “Changes since v1:” to
summarize the changes
• (`/preview` comment)
• To send the next version: `/submit` comment again
I think that’s it. :)
I don’t think there’s a need to wait if you don’t want to.
--
Kristoffer HaugsbakkThere was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> On Wed, Jun 4, 2025, at 15:56, Patrik Weiskircher wrote:
>>>
>>> Here we mention "-S", but that flag isn't implemented yet, right?
>>>
>>> Perhaps something like:
>>>
>>> Optional parameter handling only works unambiguous with git rev-parse
>>> --parseopt when using the --stuck-long option. To prepare for future commits
>>> which add flags with optional parameters, parse with --stuck-long.
>>>
>>
>> Makes sense! Changing that. What is a good policy to resubmit
>> something? Should I wait longer? Sorry, very new here!
>
> • Force-push your branch to gitgitgadget
> • Edit the PR description with something like “Changes since v1:” to
> summarize the changes
> • (`/preview` comment)
> • To send the next version: `/submit` comment again
>
> I think that’s it. :)
>
> I don’t think there’s a need to wait if you don’t want to.
It would be nice for potential reviewers to give at least 24 hours
to ensure people anywhere on the globe have a chance to comment, and
a chance for you to respond to them, before sending your next
iteration.
Also, for future reference, when responding to a review comment that
causes you to drastically change the course of the series, you can
respond whenever you want to, but it is nice to other potential
reviewers to give at least 24 hours to voice their opinions, before
sending an updated series based on that comment, since suggested
changes in such a comment may be controversial and after seeing you
spend some time already to adjust to it, others may feel discouraged
to make you redo your series again even whey they think the
suggested changes are not taking us in the right direction.There was a problem hiding this comment.
On the Git mailing list, Patrik Weiskircher wrote (reply to this):
On Wed, Jun 4, 2025 at 11:41 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
> > On Wed, Jun 4, 2025, at 15:56, Patrik Weiskircher wrote:
> >>>
> >>> Here we mention "-S", but that flag isn't implemented yet, right?
> >>>
> >>> Perhaps something like:
> >>>
> >>> Optional parameter handling only works unambiguous with git rev-parse
> >>> --parseopt when using the --stuck-long option. To prepare for future commits
> >>> which add flags with optional parameters, parse with --stuck-long.
> >>>
> >>
> >> Makes sense! Changing that. What is a good policy to resubmit
> >> something? Should I wait longer? Sorry, very new here!
> >
> > • Force-push your branch to gitgitgadget
> > • Edit the PR description with something like “Changes since v1:” to
> > summarize the changes
> > • (`/preview` comment)
> > • To send the next version: `/submit` comment again
> >
> > I think that’s it. :)
> >
> > I don’t think there’s a need to wait if you don’t want to.
>
> It would be nice for potential reviewers to give at least 24 hours
> to ensure people anywhere on the globe have a chance to comment, and
> a chance for you to respond to them, before sending your next
> iteration.
>
> Also, for future reference, when responding to a review comment that
> causes you to drastically change the course of the series, you can
> respond whenever you want to, but it is nice to other potential
> reviewers to give at least 24 hours to voice their opinions, before
> sending an updated series based on that comment, since suggested
> changes in such a comment may be controversial and after seeing you
> spend some time already to adjust to it, others may feel discouraged
> to make you redo your series again even whey they think the
> suggested changes are not taking us in the right direction.
Makes sense! I'll keep that in mind for the future!|
User |
Optional parameter handling only works unambiguous with git rev-parse --parseopt when using the --stuck-long option. To prepare for future commits which add flags with optional parameters, parse with --stuck-long. Signed-off-by: Patrik Weiskircher <patrik@pspdfkit.com>
Allows optionally signing the commits that git subtree creates. This can be necessary when working in a repository that requires gpg signed commits. Signed-off-by: Patrik Weiskircher <patrik@pspdfkit.com>
45ae2c3 to
af5b4a6
Compare
|
User |
|
User |
|
There was a status update in the "New Topics" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will cook in 'next'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@312de21. |
|
This patch series was integrated into seen via git@2f4dc6a. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will cook in 'next'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@99ab840. |
|
This patch series was integrated into seen via git@99077b8. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will cook in 'next'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@04b836e. |
|
This patch series was integrated into seen via git@d563ce0. |
|
This patch series was integrated into seen via git@188ffa3. |
|
This patch series was integrated into seen via git@9d2d6dd. |
|
This patch series was integrated into seen via git@3e9de8f. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will cook in 'next'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@2772e9d. |
|
This patch series was integrated into seen via git@e2ee1b1. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will cook in 'next'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@adef9c1. |
|
This patch series was integrated into seen via git@0bd5683. |
|
This patch series was integrated into next via git@d3c6435. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will merge to 'master'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@9bd4476. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will merge to 'master'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@b6ade3b. |
|
There was a status update in the "Cooking" section about the branch "git subtree" (in contrib/) learns to grok GPG signing its commits. Will merge to 'master'. source: <pull.1928.v2.git.1749046597.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@afe1a7a. |
|
This patch series was integrated into master via git@afe1a7a. |
|
This patch series was integrated into next via git@afe1a7a. |
|
Closed via afe1a7a. |
This patch adds support for the -S/--gpg-sign option to the
git subtreecommand.Currently,
git subtreecreates squash and merge commits without applying GPG signatures, even when commit signing is configured viacommit.gpgSign. This causes issues in repositories that require signed commits for policy reasons.The implementation ensures that -S/--gpg-sign behaves consistently with other Git commands, passing the flag through to
git commit-treeandgit mergewhere appropriate.This change improves compatibility with workflows and repositories that enforce signed commits.
Changes have been made to this patch according to a discussion with Junio C Hamano gitster@pobox.com on my previous patch attempt.
Changes since v1:
CC: apenwarr@gmail.com, Junio C Hamano gitster@pobox.com
cc: "D. Ben Knoble" ben.knoble@gmail.com
cc: Patrik Weiskircher patrik.weiskircher@nutrient.io
cc: "Kristoffer Haugsbakk" kristofferhaugsbakk@fastmail.com