1. 05 11月, 2018 1 次提交
  2. 30 8月, 2018 2 次提交
    • J
      convert "hashcmp() != 0" to "!hasheq()" · 67947c34
      Jeff King 提交于
      This rounds out the previous three patches, covering the
      inequality logic for the "hash" variant of the functions.
      
      As with the previous three, the accompanying code changes
      are the mechanical result of applying the coccinelle patch;
      see those patches for more discussion.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      67947c34
    • J
      convert "oidcmp() == 0" to oideq() · 4a7e27e9
      Jeff King 提交于
      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
      here).
      
      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: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4a7e27e9
  3. 19 7月, 2018 1 次提交
  4. 30 6月, 2018 2 次提交
  5. 12 6月, 2018 1 次提交
  6. 01 6月, 2018 1 次提交
    • J
      index-pack: handle --strict checks of non-repo packs · 368b4e59
      Jeff King 提交于
      Commit 73c3f0f7 (index-pack: check .gitmodules files with
      --strict, 2018-05-04) added a call to add_packed_git(), with
      the intent that the newly-indexed objects would be available
      to the process when we run fsck_finish().  But that's not
      what add_packed_git() does. It only allocates the struct,
      and you must install_packed_git() on the result. So that
      call was effectively doing nothing (except leaking a
      struct).
      
      But wait, we passed all of the tests! Does that mean we
      don't need the call at all?
      
      For normal cases, no. When we run "index-pack --stdin"
      inside a repository, we write the new pack into the object
      directory. If fsck_finish() needs to access one of the new
      objects, then our initial lookup will fail to find it, but
      we'll follow up by running reprepare_packed_git() and
      looking again. That logic was meant to handle somebody else
      repacking simultaneously, but it ends up working for us
      here.
      
      But there is a case that does need this, that we were not
      testing. You can run "git index-pack foo.pack" on any file,
      even when it is not inside the object directory. Or you may
      not even be in a repository at all! This case fails without
      doing the proper install_packed_git() call.
      
      We can make this work by adding the install call.
      
      Note that we should be prepared to handle add_packed_git()
      failing. We can just silently ignore this case, though. If
      fsck_finish() later needs the objects and they're not
      available, it will complain itself. And if it doesn't
      (because we were able to resolve the whole fsck in the first
      pass), then it actually isn't an interesting error at all.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      368b4e59
  7. 22 5月, 2018 2 次提交
    • J
      index-pack: check .gitmodules files with --strict · 73c3f0f7
      Jeff King 提交于
      Now that the internal fsck code has all of the plumbing we
      need, we can start checking incoming .gitmodules files.
      Naively, it seems like we would just need to add a call to
      fsck_finish() after we've processed all of the objects. And
      that would be enough to cover the initial test included
      here. But there are two extra bits:
      
        1. We currently don't bother calling fsck_object() at all
           for blobs, since it has traditionally been a noop. We'd
           actually catch these blobs in fsck_finish() at the end,
           but it's more efficient to check them when we already
           have the object loaded in memory.
      
        2. The second pass done by fsck_finish() needs to access
           the objects, but we're actually indexing the pack in
           this process. In theory we could give the fsck code a
           special callback for accessing the in-pack data, but
           it's actually quite tricky:
      
             a. We don't have an internal efficient index mapping
      	  oids to packfile offsets. We only generate it on
      	  the fly as part of writing out the .idx file.
      
             b. We'd still have to reconstruct deltas, which means
                we'd basically have to replicate all of the
      	  reading logic in packfile.c.
      
           Instead, let's avoid running fsck_finish() until after
           we've written out the .idx file, and then just add it
           to our internal packed_git list.
      
           This does mean that the objects are "in the repository"
           before we finish our fsck checks. But unpack-objects
           already exhibits this same behavior, and it's an
           acceptable tradeoff here for the same reason: the
           quarantine mechanism means that pushes will be
           fully protected.
      
      In addition to a basic push test in t7415, we add a sneaky
      pack that reverses the usual object order in the pack,
      requiring that index-pack access the tree and blob during
      the "finish" step.
      
      This already works for unpack-objects (since it will have
      written out loose objects), but we'll check it with this
      sneaky pack for good measure.
      Signed-off-by: NJeff King <peff@peff.net>
      73c3f0f7
    • J
      index-pack: make fsck error message more specific · db5a58c1
      Jeff King 提交于
      If fsck reports an error, we say only "Error in object".
      This isn't quite as bad as it might seem, since the fsck
      code would have dumped some errors to stderr already. But it
      might help to give a little more context. The earlier output
      would not have even mentioned "fsck", and that may be a clue
      that the "fsck.*" or "*.fsckObjects" config may be relevant.
      Signed-off-by: NJeff King <peff@peff.net>
      db5a58c1
  8. 06 5月, 2018 1 次提交
    • J
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin 提交于
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      
      Let's just convert all remaining ones in one fell swoop.
      
      This trick was performed by this invocation:
      
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      033abf97
  9. 02 5月, 2018 1 次提交
  10. 26 4月, 2018 1 次提交
  11. 11 4月, 2018 2 次提交
  12. 03 4月, 2018 1 次提交
  13. 27 3月, 2018 1 次提交
  14. 16 3月, 2018 1 次提交
  15. 15 3月, 2018 5 次提交
  16. 07 3月, 2018 1 次提交
  17. 15 2月, 2018 1 次提交
  18. 03 2月, 2018 2 次提交
  19. 31 1月, 2018 1 次提交
  20. 12 12月, 2017 1 次提交
  21. 09 12月, 2017 1 次提交
    • J
      sha1_file: support lazily fetching missing objects · 8b4c0103
      Jonathan Tan 提交于
      Teach sha1_file to fetch objects from the remote configured in
      extensions.partialclone whenever an object is requested but missing.
      
      The fetching of objects can be suppressed through a global variable.
      This is used by fsck and index-pack.
      
      However, by default, such fetching is not suppressed. This is meant as a
      temporary measure to ensure that all Git commands work in such a
      situation. Future patches will update some commands to either tolerate
      missing objects (without fetching them) or be more efficient in fetching
      them.
      
      In order to determine the code changes in sha1_file.c necessary, I
      investigated the following:
       (1) functions in sha1_file.c that take in a hash, without the user
           regarding how the object is stored (loose or packed)
       (2) functions in packfile.c (because I need to check callers that know
           about the loose/packed distinction and operate on both differently,
           and ensure that they can handle the concept of objects that are
           neither loose nor packed)
      
      (1) is handled by the modification to sha1_object_info_extended().
      
      For (2), I looked at for_each_packed_object and others.  For
      for_each_packed_object, the callers either already work or are fixed in
      this patch:
       - reachable - only to find recent objects
       - builtin/fsck - already knows about missing objects
       - builtin/cat-file - warning message added in this commit
      
      Callers of the other functions do not need to be changed:
       - parse_pack_index
         - http - indirectly from http_get_info_packs
         - find_pack_entry_one
           - this searches a single pack that is provided as an argument; the
             caller already knows (through other means) that the sought object
             is in a specific pack
       - find_sha1_pack
         - fast-import - appears to be an optimization to not store a file if
           it is already in a pack
         - http-walker - to search through a struct alt_base
         - http-push - to search through remote packs
       - has_sha1_pack
         - builtin/fsck - already knows about promisor objects
         - builtin/count-objects - informational purposes only (check if loose
           object is also packed)
         - builtin/prune-packed - check if object to be pruned is packed (if
           not, don't prune it)
         - revision - used to exclude packed objects if requested by user
         - diff - just for optimization
      Signed-off-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8b4c0103
  22. 06 12月, 2017 2 次提交
    • J
      introduce fetch-object: fetch one promisor object · 88e2f9ed
      Jonathan Tan 提交于
      Introduce fetch-object, providing the ability to fetch one object from a
      promisor remote.
      
      This uses fetch-pack. To do this, the transport mechanism has been
      updated with 2 flags, "from-promisor" to indicate that the resulting
      pack comes from a promisor remote (and thus should be annotated as such
      by index-pack), and "no-dependents" to indicate that only the objects
      themselves need to be fetched (but fetching additional objects is
      nevertheless safe).
      
      Whenever "no-dependents" is used, fetch-pack will refrain from using any
      object flags, because it is most likely invoked as part of a dynamic
      object fetch by another Git command (which may itself use object flags).
      An alternative to this is to leave fetch-pack alone, and instead update
      the allocation of flags so that fetch-pack's flags never overlap with
      any others, but this will end up shrinking the number of flags available
      to nearly every other Git command (that is, every Git command that
      accesses objects), so the approach in this commit was used instead.
      
      This will be tested in a subsequent commit.
      Signed-off-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      88e2f9ed
    • J
      index-pack: refactor writing of .keep files · 8e29c7c3
      Jonathan Tan 提交于
      In a subsequent commit, index-pack will be taught to write ".promisor"
      files which are similar to the ".keep" files it knows how to write.
      Refactor the writing of ".keep" files, so that the implementation of
      writing ".promisor" files becomes easier.
      Signed-off-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8e29c7c3
  23. 10 10月, 2017 1 次提交
  24. 24 8月, 2017 1 次提交
    • J
      pack: move pack name-related functions · 4f39cd82
      Jonathan Tan 提交于
      Currently, sha1_file.c and cache.h contain many functions, both related
      to and unrelated to packfiles. This makes both files very large and
      causes an unclear separation of concerns.
      
      Create a new file, packfile.c, to hold all packfile-related functions
      currently in sha1_file.c. It has a corresponding header packfile.h.
      
      In this commit, the pack name-related functions are moved. Subsequent
      commits will move the other functions.
      Signed-off-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4f39cd82
  25. 27 6月, 2017 1 次提交
  26. 17 6月, 2017 1 次提交
  27. 16 6月, 2017 1 次提交
  28. 08 5月, 2017 3 次提交