archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <>
Subject: [PATCH] pulling signed tag: add howto document
Date: Tue, 17 Jan 2012 15:29:48 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Junio C. Hamano's message of "Tue, 17 Jan 2012 14:53:01 -0800")

This time in a proper patch format...

Signed-off-by: Junio C Hamano <>
 * We may want to update Documentation/Makefile in such a way that we
   do not have to manually maintain a subset of howto/ files that need to
   be added to SP_ARTICLES list (i.e. asciidoc formatted). They are all
   marked with "Content-type: text/asciidoc" so a trivial $(shell grep -l) 
   might be all it takes. Hint, hint...

 Documentation/Makefile                             |    5 +-
 .../howto/using-signed-tag-in-pull-request.txt     |  221 ++++++++++++++++++++
 2 files changed, 225 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/howto/using-signed-tag-in-pull-request.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 116f175..d40e211 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -20,7 +20,10 @@ ARTICLES += everyday
 ARTICLES += git-tools
 ARTICLES += git-bisect-lk2009
 # with their own formatting rules.
-SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
+SP_ARTICLES = user-manual
+SP_ARTICLES += howto/revert-branch-rebase
+SP_ARTICLES += howto/using-merge-subtree
+SP_ARTICLES += howto/using-signed-tag-in-pull-request
 API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
 SP_ARTICLES += technical/api-index
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
new file mode 100644
index 0000000..a057f9a
--- /dev/null
+++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
@@ -0,0 +1,221 @@
+From: Junio C Hamano <>
+Date: Tue, 17 Jan 2011 13:00:00 -0800
+Subject: Using signed tag in pull requests
+Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
+ publishing repository and ask her integrator to pull it. This assures the
+ integrator that the pulled history is authentic and allows others to
+ later validate it.
+Content-type: text/asciidoc
+Using signed tag in pull requests
+A typical distributed workflow using Git is for a contributor to fork a
+project, build on it, publish the result to her public repository, and ask
+the "upstream" person (often the owner of the project where she forked
+from) to pull from her public repository. Requesting such a "pull" is made
+easy by the `git request-pull` command.
+Earlier, a typical pull request may have started like this:
+ The following changes since commit 406da78032179...:
+   Froboz 3.2 (2011-09-30 14:20:57 -0700)
+ are available in the git repository at:
+ for-xyzzy
+followed by a shortlog of the changes and a diffstat.
+The request was for a branch name (e.g. `for-xyzzy`) in the public
+repository of the contributor, and even though it stated where the
+contributor forked her work from, the message did not say anything about
+the commit to expect at the tip of the for-xyzzy branch. If the site that
+hosts the public repository of the contributor cannot be fully trusted, it
+was unnecessarily hard to make sure what was pulled by the integrator was
+genuinely what the contributor had produced for the project. Also there
+was no easy way for third-party auditors to later verify the resulting
+Starting from Git release v1.7.9, a contributor can add a signed tag to
+the commit at the tip of the history and ask the integrator to pull that
+signed tag. When the integrator runs `git pull`, the signed tag is
+automatically verified to assure that the history is not tampered with.
+In addition, the resulting merge commit records the content of the signed
+tag, so that other people can verify that the branch merged by the
+contributor was signed by the contributor, without fetching the signed tag
+used to validate the pull request separately and keeping it in the refs
+This document describes the workflow between the contributor and the
+integrator, using Git v1.7.9 or later.
+A contributor or a lieutenant
+After preparing her work to be pulled, the contributor uses `git tag -s`
+to create a signed tag [*1*]:
+ $ git checkout work
+ $ ... "git pull" from sublieutenants, "git commit" your own work ...
+ $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
+and pushes the tag out to her publishing repository [*2*]. There is no
+need to push the `work` branch or anything else:
+ $ git push +frotz-for-xyzzy
+Then the contributor prepares a message to request a "pull":
+ $ git request-pull v3.2 frotz-for-xyzzy >msg.txt
+The arguments are:
+. the version of the integrator's commit the contributor based her work on;
+. the URL of the repository, to which the contributor has pushed what she
+  wants to get pulled; and
+. the name of the tag the contributor wants to get pulled (earlier, she could
+  write only a branch name here).
+The resulting msg.txt file begins like so:
+ The following changes since commit 406da78032179...:
+   Froboz 3.2 (2011-09-30 14:20:57 -0700)
+ are available in the git repository at:
+ frotz-for-xyzzy
+ for you to fetch changes up to 703f05ad5835c...:
+   Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
+ -----------------------------------------------
+ Completed frotz feature
+ -----------------------------------------------
+followed by a shortlog of the changes and a diffstat.  Comparing this with
+the earlier illustration of the output from the traditional `git request-pull`
+command, the reader should notice that:
+. The tip commit to expect is shown to the integrator; and
+. The signed tag message is shown prominently between the dashed lines
+  before the shortlog.
+The latter is why the contributor would want to justify why pulling her
+work is worthwhile when creating the signed tag.  The contributor then
+opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
+After receiving such a pull request message, the integrator fetches and
+integrates the tag named in the request, with:
+ $ git pull frotz-for-xyzzy
+This operation will always open an editor to allow the integrator to fine
+tune the commit log message when merging a signed tag.  Also, pulling a
+signed tag will always create a merge commit even when the integrator does
+not have any new commits since the contributor's work forked (i.e. 'fast
+forward'), so that the integrator can properly explain what the merge is
+about and why it was made.
+In the editor, the integrator will see something like this:
+ Merge tag 'frotz-for-xyzzy' of
+ Completed frotz feature
+ # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
+ # gpg: Good signature from "Con Tributor <>"
+provided if the signature in the signed tag verifies correctly. Notice
+that the message recorded in the signed tag "Completed frotz feature"
+appears here, and again that is why it is important for the contributor
+to explain her work well when creating the signed tag.
+As usual, the lines commented with `#` are stripped out. The resulting
+commit records the signed tag used for this validation in a hidden field
+so that it can later be used by others to audit the history. There is no
+need for the integrator to keep a separate copy of the tag in his
+repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
+example), and there is no need to publish the tag to his public
+repository, either.
+After the integrator responds to the pull request and her work becomes
+part of the permanent history, the contributor can remove the tag from the
+publishing repository, if she chooses, in order to keep the tag namespace
+of her public repository clean, with:
+ $ git push :frotz-for-xyzzy
+The `--show-signature` option can be given to `git log` or `git show` and
+shows the verification status of the embedded signed tag in merge commits
+created when the integrator responded to a pull request of a signed tag.
+A typical output from `git show --show-signature` may look like this:
+ $ git show --show-signature
+ commit 02306ef6a3498a39118aef9df7975bdb50091585
+ merged tag 'frotz-for-xyzzy'
+ gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
+ gpg: Good signature from "Con Tributor <>"
+ Merge: 406da78 703f05a
+ Author: Inte Grator <>
+ Date:   Tue Jan 17 13:49:41 2012 -0800
+     Merge tag 'frotz-for-xyzzy'
+     Completed frotz feature
+     * tag 'frotz-for-xyzzy' (100 commits)
+       Add tests and documentation for frotz
+       ...
+There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
+that is used for frequent "pull" exchange in the long term just for such
+auditing purposes, as the signature is recorded as part of the merge
+*1* This example uses the `-m` option to create a signed tag with just a
+single liner message, but this is for illustration purposes only. It is
+advisable to compose a well-written explanation of what the topic does to
+justify why it is worthwhile for the integrator to pull it, as this
+message will eventually become part of the final history after the
+integrator responds to the pull request.
+*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
+forcing the update of a tag, as the same contributor may want to reuse a
+signed tag with the same name after the previous pull request has already
+been responded to.

  reply	other threads:[~2012-01-17 23:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17 22:53 Using signed tag in pull requests Junio C Hamano
2012-01-17 23:29 ` Junio C Hamano [this message]
2012-01-18 15:15   ` [PATCH] pulling signed tag: add howto document Marc Branchaud
2012-01-18 21:22     ` Junio C Hamano
2012-01-18 21:40       ` Marc Branchaud
2012-01-18 22:27         ` Junio C Hamano
2012-01-18 22:35           ` Marc Branchaud
2012-01-18  1:07 ` Using signed tag in pull requests Andrew Ardill
2012-01-18  1:47   ` Junio C Hamano
2012-01-18  2:34     ` Andrew Ardill

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:

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

  git send-email \ \ \ \
    --subject='Re: [PATCH] pulling signed tag: add howto document' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).