1. 29 Jun, 2018 1 commit
  2. 16 May, 2018 1 commit
    • Stefan Beller's avatar
      object-store: move object access functions to object-store.h · cbd53a21
      Stefan Beller authored
      This should make these functions easier to find and cache.h less
      overwhelming to read.
      In particular, this moves:
      - read_object_file
      - oid_object_info
      - write_object_file
      As a result, most of the codebase needs to #include object-store.h.
      In this patch the #include is only added to files that would fail to
      compile otherwise.  It would be better to #include wherever
      identifiers from the header are used.  That can happen later
      when we have better tooling for it.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 14 Mar, 2018 1 commit
    • brian m. carlson's avatar
      sha1_file: convert read_sha1_file to struct object_id · b4f5aca4
      brian m. carlson authored
      Convert read_sha1_file to take a pointer to struct object_id and rename
      it read_object_file.  Do the same for read_sha1_file_extended.
      Convert one use in grep.c to use the new function without any other code
      change, since the pointer being passed is a void pointer that is already
      initialized with a pointer to struct object_id.  Update the declaration
      and definitions of the modified functions, and apply the following
      semantic patch to convert the remaining callers:
      expression E1, E2, E3;
      - read_sha1_file(E1.hash, E2, E3)
      + read_object_file(&E1, E2, E3)
      expression E1, E2, E3;
      - read_sha1_file(E1->hash, E2, E3)
      + read_object_file(E1, E2, E3)
      expression E1, E2, E3, E4;
      - read_sha1_file_extended(E1.hash, E2, E3, E4)
      + read_object_file_extended(&E1, E2, E3, E4)
      expression E1, E2, E3, E4;
      - read_sha1_file_extended(E1->hash, E2, E3, E4)
      + read_object_file_extended(E1, E2, E3, E4)
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 30 Jan, 2018 3 commits
  5. 16 Oct, 2017 2 commits
  6. 02 Jun, 2017 2 commits
  7. 08 May, 2017 2 commits
    • brian m. carlson's avatar
      Convert lookup_commit* to struct object_id · bc83266a
      brian m. carlson authored
      Convert lookup_commit, lookup_commit_or_die,
      lookup_commit_reference, and lookup_commit_reference_gently to take
      struct object_id arguments.
      Introduce a temporary in parse_object buffer in order to convert this
      function.  This is required since in order to convert parse_object and
      parse_object_buffer, lookup_commit_reference_gently and
      lookup_commit_or_die would need to be converted.  Not introducing a
      temporary would therefore require that lookup_commit_or_die take a
      struct object_id *, but lookup_commit would take unsigned char *,
      leaving a confusing and hard-to-use interface.
      parse_object_buffer will lose this temporary in a later patch.
      This commit was created with manual changes to commit.c, commit.h, and
      object.c, plus the following semantic patch:
      expression E1, E2;
      - lookup_commit_reference_gently(E1.hash, E2)
      + lookup_commit_reference_gently(&E1, E2)
      expression E1, E2;
      - lookup_commit_reference_gently(E1->hash, E2)
      + lookup_commit_reference_gently(E1, E2)
      expression E1;
      - lookup_commit_reference(E1.hash)
      + lookup_commit_reference(&E1)
      expression E1;
      - lookup_commit_reference(E1->hash)
      + lookup_commit_reference(E1)
      expression E1;
      - lookup_commit(E1.hash)
      + lookup_commit(&E1)
      expression E1;
      - lookup_commit(E1->hash)
      + lookup_commit(E1)
      expression E1, E2;
      - lookup_commit_or_die(E1.hash, E2)
      + lookup_commit_or_die(&E1, E2)
      expression E1, E2;
      - lookup_commit_or_die(E1->hash, E2)
      + lookup_commit_or_die(E1, E2)
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • brian m. carlson's avatar
      notes-cache: convert to struct object_id · 569aa376
      brian m. carlson authored
      Convert as many instances of unsigned char [20] as possible.  Update the
      callers of notes_cache_get and notes_cache_put to use the new interface.
      Among the functions updated are callers of
      lookup_commit_reference_gently, which we will soon convert.
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 12 Jan, 2016 1 commit
    • Mike Hommey's avatar
      notes: allow treeish expressions as notes ref · ee76f92f
      Mike Hommey authored
      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: default avatarMike Hommey <mh@glandium.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  9. 12 Jun, 2014 2 commits
    • Jeff King's avatar
      replace dangerous uses of strbuf_attach · e6dfcd67
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      commit_tree: take a pointer/len pair rather than a const strbuf · 3ffefb54
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 07 Apr, 2014 1 commit
  11. 15 Dec, 2011 1 commit
  12. 13 Nov, 2011 1 commit
    • Junio C Hamano's avatar
      commit: teach --gpg-sign option · ba3c69a9
      Junio C Hamano authored
      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 <gitster@pobox.com>"
          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 b87755351a47b09cb27d6913e6e0e17e6254a4d4
          author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
          committer Junio C Hamano <gitster@pobox.com> 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: default avatarJunio C Hamano <gitster@pobox.com>
  13. 17 Nov, 2010 1 commit
    • Johan Herland's avatar
      notes.h/c: Propagate combine_notes_fn return value to add_note() and beyond · 180619a5
      Johan Herland authored
      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 <jrnieder@gmail.com>
      Signed-off-by: default avatarJohan Herland <johan@herland.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  14. 02 Apr, 2010 1 commit
    • Jeff King's avatar
      introduce notes-cache interface · a941d5e3
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>