git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 09/10] fmt-merge-msg: Add contents of merged tag in the merge message
Date: Sat, 05 Nov 2011 09:43:57 +0100	[thread overview]
Message-ID: <4EB4F74D.7090004@kdbg.org> (raw)
In-Reply-To: <1320472900-6601-10-git-send-email-gitster@pobox.com>

Am 05.11.2011 07:01, schrieb Junio C Hamano:
> When a contributor asks the integrator to merge her history, a signed tag
> can be a good vehicle to communicate the authenticity of the request while
> conveying other information such as the purpose of the topic.
> 
> E.g. a signed tag "for-linus" can be created, and the integrator can run:
> 
>    $ git pull git://example.com/work.git/ for-linus
> 
> This would allow the integrator to run "git verify-tag FETCH_HEAD" to
> validate the signed tag.
> 
> While we do not necessarily want to clutter the global tag namespace of
> the project, we would want to leave enough information in the repository
> to allow third party to later validate the resulting history.
> 
> Update fmt-merge-msg that prepares the merge message template, and store
> the contents of the signed tag object and the message that comes from GPG
> signature validation at the end of it. The integrator can choose to leave
> the contents of the tag in the resulting merge commit, or can choose to
> remove it. The GPG validation message is inserted as a comment only to
> help the integrator to review the validation result but otherwise will not
> be recorded in the resulting merge commit, because later validation by
> third parties does not need it.

Since the tag signature depends on the tag message, including all spelin
errors, the integrator must not change the text so that third parties
can repeat the verification. (Correct?) I assume this is the reason that
you put 'tag:' in front of the tag message, to discourage any changes.

What if the tag is not signed? Does this code path trigger at all? In
this case, I would prefer that the discouraging 'tag:' prefix were not
present. The resulting text would fit more naturally in a commit message
as a description of the commit/merge/topic. What do you think?

-- Hannes

  reply	other threads:[~2011-11-05  8:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-05  6:01 [PATCH 00/10] Pulling signed tag Junio C Hamano
2011-11-05  6:01 ` [PATCH 01/10] Split GPG interface into its own helper library Junio C Hamano
2011-11-05  6:01 ` [PATCH 02/10] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-05  6:01 ` [PATCH 03/10] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-05  6:01 ` [PATCH 04/10] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-05  6:01 ` [PATCH 05/10] tests: distinguish merges of tags and commits Junio C Hamano
2011-11-05  6:01 ` [PATCH 06/10] refs DWIMmery: use the same rule for both "git fetch" and others Junio C Hamano
2011-11-05  6:01 ` [PATCH 07/10] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-05  6:01 ` [PATCH 08/10] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-05  6:01 ` [PATCH 09/10] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-05  8:43   ` Johannes Sixt [this message]
2011-11-06  6:03     ` Junio C Hamano
2011-11-05  6:01 ` [PATCH 10/10] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-05  9:27 ` [PATCH 00/10] Pulling signed tag Nguyen Thai Ngoc Duy
2011-11-08  3:00 ` [PATCH v2 00/12] Pulling signed/annotated tags Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 01/12] Split GPG interface into its own helper library Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 02/12] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 03/12] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 04/12] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 05/12] refs DWIMmery: use the same rule for both "git fetch" and others Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 06/12] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 07/12] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 08/12] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 09/12] merge: make usage of commit->util more extensible Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 10/12] merge: record tag objects without peeling in MERGE_HEAD Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 11/12] commit: copy merged signed tags to headers of merge commit Junio C Hamano
2011-11-08  3:00   ` [PATCH v2 12/12] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-08  4:20   ` [PATCH v2 00/12] Pulling signed/annotated tags Linus Torvalds
2011-11-08  5:10     ` Junio C Hamano
2011-11-08  5:31       ` Linus Torvalds
2011-11-08  5:37         ` Junio C Hamano
2011-11-08 21:45           ` Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB4F74D.7090004@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
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 NNTP newsgroup(s).