Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Oct 8, 2015
  1. @glandium @gitster

    notes: allow treeish expressions as notes ref

    glandium committed with gitster
    init_notes() is the main point of entry to the notes API. It ensures
    that the input can be used as ref, because it needs a ref to update to
    store notes tree after modifying it.
    There however are many use cases where notes tree is only read, e.g.
    "git log --notes=...".  Any notes-shaped treeish could be used for such
    purpose, but it is not allowed due to existing restriction.
    Allow treeish expressions to be used in the case the notes tree is going
    to be used without write "permissions".  Add a flag to distinguish
    whether the notes tree is intended to be used read-only, or will be
    With this change, operations that use notes read-only can be fed any
    notes-shaped tree-ish can be used, e.g. git log --notes=notes@{1}.
    Signed-off-by: Mike Hommey <>
    Signed-off-by: Junio C Hamano <>
Commits on Jul 2, 2014
  1. @gitster

    Merge branch 'jk/commit-buffer-length'

    gitster committed
    Move "commit->buffer" out of the in-core commit object and keep
    track of their lengths.  Use this to optimize the code paths to
    validate GPG signatures in commit objects.
    * jk/commit-buffer-length:
      reuse cached commit buffer when parsing signatures
      commit: record buffer length in cache
      commit: convert commit->buffer to a slab
      commit-slab: provide a static initializer
      use get_commit_buffer everywhere
      convert logmsg_reencode to get_commit_buffer
      use get_commit_buffer to avoid duplicate code
      use get_cached_commit_buffer where appropriate
      provide helpers to access the commit buffer
      provide a helper to set the commit buffer
      provide a helper to free commit buffer
      sequencer: use logmsg_reencode in get_message
      logmsg_reencode: return const buffer
      do not create "struct commit" with xcalloc
      commit: push commit_index update into alloc_commit_node
      alloc: include any-object allocations in alloc_report
      replace dangerous uses of strbuf_attach
      commit_tree: take a pointer/len pair rather than a const strbuf
Commits on Jun 12, 2014
  1. @peff @gitster

    replace dangerous uses of strbuf_attach

    peff committed with gitster
    It is not a good idea to strbuf_attach an arbitrary pointer
    just because a function you are calling wants a strbuf.
    Attaching implies a transfer of memory ownership; if anyone
    were to modify or release the resulting strbuf, we would
    free() the pointer, leading to possible problems:
      1. Other users of the original pointer might access freed
      2. The pointer might not be the start of a malloc'd
         area, so calling free() on it in the first place would
         be wrong.
    In the two cases modified here, we are fortunate that nobody
    touches the strbuf once it is attached, but it is an
    accident waiting to happen.  Since the previous commit,
    commit_tree and friends take a pointer/buf pair, so we can
    just do away with the strbufs entirely.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
  2. @peff @gitster

    commit_tree: take a pointer/len pair rather than a const strbuf

    peff committed with gitster
    While strbufs are pretty common throughout our code, it is
    more flexible for functions to take a pointer/len pair than
    a strbuf. It's easy to turn a strbuf into such a pair (by
    dereferencing its members), but less easy to go the other
    way (you can strbuf_attach, but that has implications about
    memory ownership).
    This patch teaches commit_tree (and its associated callers
    and sub-functions) to take such a pair for the commit
    message rather than a strbuf.  This makes passing the buffer
    around slightly more verbose, but means we can get rid of
    some dangerous strbuf_attach calls in the next patch.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Apr 7, 2014
  1. @mhagger @gitster

    refs.h: rename the action_on_err constants

    mhagger committed with gitster
    Given that these constants are only being used when updating
    references, it is inappropriate to give them such generic names as
    "DIE_ON_ERR".  So prefix their names with "UPDATE_REFS_".
    Signed-off-by: Michael Haggerty <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 6, 2012
  1. @gitster

    Merge branch 'jc/show-sig'

    gitster committed
    * 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
    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
    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
    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
    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.