Skip to content
Commits on Jan 6, 2012
  1. @gitster

    Merge branch 'jc/show-sig'

    gitster committed Jan 6, 2012
    * jc/show-sig:
      log --show-signature: reword the common two-head merge case
      log-tree: show mergetag in log --show-signature output
      log-tree.c: small refactor in show_signature()
      commit --amend -S: strip existing gpgsig headers
      verify_signed_buffer: fix stale comment
      gpg-interface: allow use of a custom GPG binary
      pretty: %G[?GS] placeholders
      test "commit -S" and "log --show-signature"
      log: --show-signature
      commit: teach --gpg-sign option
Commits on Dec 15, 2011
  1. @pclouds @gitster

    Convert commit_tree() to take strbuf as message

    pclouds committed with gitster Dec 15, 2011
    There wan't a way for commit_tree() to notice if the message the caller
    prepared contained a NUL byte, as it did not take the length of the
    message as a parameter. Use a pointer to a strbuf instead, so that we can
    either choose to allow low-level plumbing commands to make commits that
    contain NUL byte in its message, or forbid NUL everywhere by adding the
    check in commit_tree(), in later patches.
    Signed-off-by: Nguyễn Thái Ngọc Duy <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 13, 2011
  1. @gitster

    commit: teach --gpg-sign option

    gitster committed Oct 5, 2011
    This uses the gpg-interface.[ch] to allow signing the commit, i.e.
        $ git commit --gpg-sign -m foo
        You need a passphrase to unlock the secret key for
        user: "Junio C Hamano <>"
        4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
        [master 8457d13] foo
         1 files changed, 1 insertions(+), 0 deletions(-)
    The lines of GPG detached signature are placed in a new multi-line header
    field, instead of tucking the signature block at the end of the commit log
    message text (similar to how signed tag is done), for multiple reasons:
     - The signature won't clutter output from "git log" and friends if it is
       in the extra header. If we place it at the end of the log message, we
       would need to teach "git log" and friends to strip the signature block
       with an option.
     - Teaching new versions of "git log" and "gitk" to optionally verify and
       show signatures is cleaner if we structurally know where the signature
       block is (instead of scanning in the commit log message).
     - The signature needs to be stripped upon various commit rewriting
       operations, e.g. rebase, filter-branch, etc. They all already ignore
       unknown headers, but if we place signature in the log message, all of
       these tools (and third-party tools) also need to learn how a signature
       block would look like.
     - When we added the optional encoding header, all the tools (both in tree
       and third-party) that acts on the raw commit object should have been
       fixed to ignore headers they do not understand, so it is not like that
       new header would be more likely to break than extra text in the commit.
    A commit made with the above sample sequence would look like this:
        $ git cat-file commit HEAD
        tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
        parent b877553
        author Junio C Hamano <> 1317862251 -0700
        committer Junio C Hamano <> 1317862251 -0700
        gpgsig -----BEGIN PGP SIGNATURE-----
         Version: GnuPG v1.4.10 (GNU/Linux)
         -----END PGP SIGNATURE-----
    but "git log" (unless you ask for it with --pretty=raw) output is not
    cluttered with the signature information.
    Signed-off-by: Junio C Hamano <>
Commits on Nov 17, 2010
  1. @jherland @gitster

    notes.h/c: Propagate combine_notes_fn return value to add_note() and …

    jherland committed with gitster Nov 15, 2010
    The combine_notes_fn functions uses a non-zero return value to indicate
    failure. However, this return value was converted to a call to die()
    in note_tree_insert().
    Instead, propagate this return value out to add_note(), and return it
    from there to enable the caller to handle errors appropriately.
    Existing add_note() callers are updated to die() upon failure, thus
    preserving the current behaviour. The only exceptions are copy_note()
    and notes_cache_put() where we are able to propagate the add_note()
    return value instead.
    This patch has been improved by the following contributions:
    - Jonathan Nieder: Future-proof by always checking add_note() return value
    - Jonathan Nieder: Improve clarity of final if-condition in note_tree_insert()
    Thanks-to: Jonathan Nieder <>
    Signed-off-by: Johan Herland <>
    Signed-off-by: Junio C Hamano <>
Commits on Apr 2, 2010
  1. @peff @gitster

    introduce notes-cache interface

    peff committed with gitster Apr 1, 2010
    Notes provide a fast lookup mechanism for data keyed by
    sha1. This is ideal for caching certain operations, like
    textconv filters.
    This patch builds some infrastructure to make it simpler to
    use notes trees as caches. In particular, caches:
      1. don't have arbitrary commit messages. They store a
         cache validity string in the commit, and clear the tree
         when the cache validity string changes.
      2. don't keep any commit history. The accumulated history
         of a a cache is just useless cruft.
      3. use a looser form of locking for ref updates. If two
         processes try to write to the cache simultaneously, it
         is OK if one overwrites the other, losing some changes.
         It's just a cache, so we will just end up with an extra
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.