1. 15 Jan, 2019 1 commit
    • brian m. carlson's avatar
      tree-walk: store object_id in a separate member · ea82b2a0
      brian m. carlson authored
      When parsing a tree, we read the object ID directly out of the tree
      buffer. This is normally fine, but such an object ID cannot be used with
      oidcpy, which copies GIT_MAX_RAWSZ bytes, because if we are using SHA-1,
      there may not be that many bytes to copy.
      Instead, store the object ID in a separate struct member. Since we can
      no longer efficiently compute the path length, store that information as
      well in struct name_entry. Ensure we only copy the object ID into the
      new buffer if the path length is nonzero, as some callers will pass us
      an empty path with no object ID following it, and we will not want to
      read past the end of the buffer.
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 29 Aug, 2018 3 commits
    • Jeff King's avatar
      convert "oidcmp() != 0" to "!oideq()" · 9001dc2a
      Jeff King authored
      This is the flip side of the previous two patches: checking
      for a non-zero oidcmp() can be more strictly expressed as
      inequality. Like those patches, we write "!= 0" in the
      coccinelle transformation, which covers by isomorphism the
      more common:
        if (oidcmp(E1, E2))
      As with the previous two patches, this patch can be achieved
      almost entirely by running "make coccicheck"; the only
      differences are manual line-wrap fixes to match the original
      There is one thing to note for anybody replicating this,
      though: coccinelle 1.0.4 seems to miss the case in
      builtin/tag.c, even though it's basically the same as all
      the others. Running with 1.0.7 does catch this, so
      presumably it's just a coccinelle bug that was fixed in the
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      convert "hashcmp() == 0" to hasheq() · e3ff0683
      Jeff King authored
      This is the partner patch to the previous one, but covering
      the "hash" variants instead of "oid".  Note that our
      coccinelle rule is slightly more complex to avoid triggering
      the call in hasheq().
      I didn't bother to add a new rule to convert:
        - hasheq(E1->hash, E2->hash)
        + oideq(E1, E2)
      Since these are new functions, there won't be any such
      existing callers. And since most of the code is already
      using oideq, we're not likely to introduce new ones.
      We might still see "!hashcmp(E1->hash, E2->hash)" from topics
      in flight. But because our new rule comes after the existing
      ones, that should first get converted to "!oidcmp(E1, E2)"
      and then to "oideq(E1, E2)".
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      convert "oidcmp() == 0" to oideq() · 4a7e27e9
      Jeff King authored
      Using the more restrictive oideq() should, in the long run,
      give the compiler more opportunities to optimize these
      callsites. For now, this conversion should be a complete
      noop with respect to the generated code.
      The result is also perhaps a little more readable, as it
      avoids the "zero is equal" idiom. Since it's so prevalent in
      C, I think seasoned programmers tend not to even notice it
      anymore, but it can sometimes make for awkward double
      negations (e.g., we can drop a few !!oidcmp() instances
      This patch was generated almost entirely by the included
      coccinelle patch. This mechanical conversion should be
      completely safe, because we check explicitly for cases where
      oidcmp() is compared to 0, which is what oideq() is doing
      under the hood. Note that we don't have to catch "!oidcmp()"
      separately; coccinelle's standard isomorphisms make sure the
      two are treated equivalently.
      I say "almost" because I did hand-edit the coccinelle output
      to fix up a few style violations (it mostly keeps the
      original formatting, but sometimes unwraps long lines).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 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>
  4. 14 Mar, 2018 2 commits
    • 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>
    • brian m. carlson's avatar
      tree-walk: convert tree entry functions to object_id · 916bc35b
      brian m. carlson authored
      Convert get_tree_entry and find_tree_entry to take pointers to struct
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 30 Jan, 2018 3 commits
  6. 01 Nov, 2017 1 commit
  7. 16 Oct, 2017 1 commit
  8. 08 Sep, 2017 1 commit
  9. 26 Aug, 2017 12 commits
  10. 14 Aug, 2017 1 commit
  11. 17 Jul, 2017 1 commit
    • brian m. carlson's avatar
      sha1_name: convert get_sha1* to get_oid* · e82caf38
      brian m. carlson authored
      Now that all the callers of get_sha1 directly or indirectly use struct
      object_id, rename the functions starting with get_sha1 to start with
      get_oid.  Convert the internals in sha1_name.c to use struct object_id
      as well, and eliminate explicit length checks where possible.  Convert a
      use of 40 in get_oid_basic to GIT_SHA1_HEXSZ.
      Outside of sha1_name.c and cache.h, this transition was made with the
      following semantic patch:
      expression E1, E2;
      - get_sha1(E1, E2.hash)
      + get_oid(E1, &E2)
      expression E1, E2;
      - get_sha1(E1, E2->hash)
      + get_oid(E1, E2)
      expression E1, E2;
      - get_sha1_committish(E1, E2.hash)
      + get_oid_committish(E1, &E2)
      expression E1, E2;
      - get_sha1_committish(E1, E2->hash)
      + get_oid_committish(E1, E2)
      expression E1, E2;
      - get_sha1_treeish(E1, E2.hash)
      + get_oid_treeish(E1, &E2)
      expression E1, E2;
      - get_sha1_treeish(E1, E2->hash)
      + get_oid_treeish(E1, E2)
      expression E1, E2;
      - get_sha1_commit(E1, E2.hash)
      + get_oid_commit(E1, &E2)
      expression E1, E2;
      - get_sha1_commit(E1, E2->hash)
      + get_oid_commit(E1, E2)
      expression E1, E2;
      - get_sha1_tree(E1, E2.hash)
      + get_oid_tree(E1, &E2)
      expression E1, E2;
      - get_sha1_tree(E1, E2->hash)
      + get_oid_tree(E1, E2)
      expression E1, E2;
      - get_sha1_blob(E1, E2.hash)
      + get_oid_blob(E1, &E2)
      expression E1, E2;
      - get_sha1_blob(E1, E2->hash)
      + get_oid_blob(E1, E2)
      expression E1, E2, E3, E4;
      - get_sha1_with_context(E1, E2, E3.hash, E4)
      + get_oid_with_context(E1, E2, &E3, E4)
      expression E1, E2, E3, E4;
      - get_sha1_with_context(E1, E2, E3->hash, E4)
      + get_oid_with_context(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>
  12. 15 Jun, 2017 1 commit
  13. 02 Jun, 2017 6 commits
  14. 28 Mar, 2017 1 commit
    • Mike Hommey's avatar
      notes: do not break note_tree structure in note_tree_consolidate() · 5a8e7c34
      Mike Hommey authored
      After a note is removed, note_tree_consolidate is called to eliminate
      some useless nodes. The typical case is that if you had an int_node
      with 2 PTR_TYPE_NOTEs in it, and remove one of them, then the
      PTR_TYPE_INTERNAL pointer in the parent tree can be replaced with the
      remaining PTR_TYPE_NOTE.
      This works fine when PTR_TYPE_NOTEs are involved, but falls flat when
      other types are involved.
      To put things in more practical terms, let's say we start from an empty
      notes tree, and add 3 notes:
      - one for a sha1 that starts with 424
      - one for a sha1 that starts with 428
      - one for a sha1 that starts with 4c
      To keep track of this, note_tree.root will have a PTR_TYPE_INTERNAL at
      a[4], pointing to an int_node*.
      In turn, that int_node* will have a PTR_TYPE_NOTE at a[0xc], pointing to
      the leaf_node* with the key and value, and a PTR_TYPE_INTERNAL at a[2],
      pointing to another int_node*.
      That other int_node* will have 2 PTR_TYPE_NOTE, one at a[4] and the
      other at a[8].
      When looking for the note for the sha1 starting with 428, get_note() will
      recurse through (simplified) root.a[4].a[2].a[8].
      Now, if we remove the note for the sha1 that starts with 4c, we're left
      with a int_node* with only one PTR_TYPE_INTERNAL entry in it. After
      note_tree_consolidate runs, root.a[4] now points to what used to be
      pointed at by root.a[4].a[2].
      Which means looking up for the note for the sha1 starting with 428 now
      fails because there is nothing at root.a[4].a[2] anymore: there is only
      root.a[4].a[4] and root.a[4].a[8], which don't match the expected
      structure for the lookup.
      So if all there is left in an int_node* is a PTR_TYPE_INTERNAL pointer,
      we can't safely remove it. I think the same applies for PTR_TYPE_SUBTREE
      pointers. IOW, only PTR_TYPE_NOTEs are safe to be moved to the parent
      This doesn't have a practical effect on git because all that happens
      after a remove_note is a write_notes_tree, which just iterates the entire
      note tree, but this affects anything using libgit.a that would try to do
      lookups after removing notes.
      Signed-off-by: default avatarMike Hommey <mh@glandium.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  15. 07 Sep, 2016 1 commit
  16. 13 Jun, 2016 1 commit
    • Jeff King's avatar
      use string_list initializer consistently · 2721ce21
      Jeff King authored
      There are two types of string_lists: those that own the
      string memory, and those that don't. You can tell the
      difference by the strdup_strings flag, and one should use
      Historically, the normal all-zeros initialization has
      corresponded to the NODUP case. Many sites use no
      initializer at all, and that works as a shorthand for that
      case. But for a reader of the code, it can be hard to
      remember which is which. Let's be more explicit and actually
      have each site declare which type it means to use.
      This is a fairly mechanical conversion; I assumed each site
      was correct as-is, and just switched them all to NODUP.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  17. 25 Apr, 2016 1 commit
  18. 22 Feb, 2016 1 commit
  19. 17 Jan, 2016 1 commit