1. 26 4月, 2018 2 次提交
  2. 27 3月, 2018 3 次提交
  3. 15 3月, 2018 4 次提交
  4. 07 3月, 2018 1 次提交
  5. 15 2月, 2018 1 次提交
  6. 03 2月, 2018 1 次提交
  7. 31 1月, 2018 1 次提交
  8. 25 1月, 2018 1 次提交
  9. 09 12月, 2017 1 次提交
  10. 22 11月, 2017 1 次提交
    • J
      pack-objects: add list-objects filtering · 9535ce73
      Jeff Hostetler 提交于
      Teach pack-objects to use the filtering provided by the
      traverse_commit_list_filtered() interface to omit unwanted
      objects from the resulting packfile.
      
      Filtering requires the use of the "--stdout" option.
      
      Add t5317 test.
      
      In the future, we will introduce a "partial clone" mechanism
      wherein an object in a repo, obtained from a remote, may
      reference a missing object that can be dynamically fetched from
      that remote once needed.  This "partial clone" mechanism will
      have a way, sometimes slow, of determining if a missing link
      is one of the links expected to be produced by this mechanism.
      
      This patch introduces handling of missing objects to help
      debugging and development of the "partial clone" mechanism,
      and once the mechanism is implemented, for a power user to
      perform operations that are missing-object aware without
      incurring the cost of checking if a missing link is expected.
      Signed-off-by: NJeff Hostetler <jeffhost@microsoft.com>
      Reviewed-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9535ce73
  11. 16 10月, 2017 3 次提交
  12. 10 10月, 2017 1 次提交
  13. 01 10月, 2017 1 次提交
  14. 22 9月, 2017 1 次提交
  15. 14 9月, 2017 1 次提交
  16. 24 8月, 2017 2 次提交
    • J
      pack: move open_pack_index(), parse_pack_index() · 0317f455
      Jonathan Tan 提交于
      alloc_packed_git() in packfile.c is duplicated from sha1_file.c. In a
      subsequent commit, alloc_packed_git() will be removed from sha1_file.c.
      Signed-off-by: NJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0317f455
    • M
      pack-objects: take lock before accessing `remaining` · 0c2ad00b
      Martin Ågren 提交于
      When checking the conditional of "while (me->remaining)", we did not
      hold the lock. Calling find_deltas would still be safe, since it checks
      "remaining" (after taking the lock) and is able to handle all values. In
      fact, this could (currently) not trigger any bug: a bug could happen if
      `remaining` transitioning from zero to non-zero races with the evaluation
      of the while-condition, but these are always separated by the
      data_ready-mechanism.
      
      Make sure we have the lock when we read `remaining`. This does mean we
      release it just so that find_deltas can take it immediately again. We
      could tweak the contract so that the lock should be taken before calling
      find_deltas, but let's defer that until someone can actually show that
      "unlock+lock" has a measurable negative impact.
      Signed-off-by: NMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0c2ad00b
  17. 21 7月, 2017 1 次提交
    • R
      pack-objects: remove unnecessary NULL check · c7b07805
      René Scharfe 提交于
      If done_pbase_paths is NULL then done_pbase_paths_num must be zero and
      done_pbase_path_pos() returns -1 without accessing the array, so the
      check is not necessary.
      
      If the invariant was violated then the check would make sure we keep
      on going and allocate the necessary amount of memory in the next
      ALLOC_GROW call.  That sounds nice, but all array entries except for
      one would contain garbage data.
      
      If the invariant was violated without the check we'd get a segfault in
      done_pbase_path_pos(), i.e. an observable crash, alerting us of the
      presence of a bug.
      
      Currently there is no such bug: Only the functions check_pbase_path()
      and cleanup_preferred_base() change pointer and counter, and both make
      sure to keep them in sync.  Get rid of the check anyway to allow us to
      see if later changes introduce such a defect, and to simplify the code.
      
      Detected by Coverity Scan.
      Signed-off-by: NRene Scharfe <l.s.r@web.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c7b07805
  18. 18 7月, 2017 1 次提交
    • R
      use MOVE_ARRAY · f331ab9d
      René Scharfe 提交于
      Simplify the code for moving members inside of an array and make it more
      robust by using the helper macro MOVE_ARRAY.  It calculates the size
      based on the specified number of elements for us and supports NULL
      pointers when that number is zero.  Raw memmove(3) calls with NULL can
      cause the compiler to (over-eagerly) optimize out later NULL checks.
      
      This patch was generated with contrib/coccinelle/array.cocci and spatch
      (Coccinelle).
      Signed-off-by: NRene Scharfe <l.s.r@web.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f331ab9d
  19. 17 6月, 2017 1 次提交
  20. 16 6月, 2017 1 次提交
  21. 26 5月, 2017 1 次提交
  22. 09 5月, 2017 1 次提交
    • J
      pack-objects: disable pack reuse for object-selection options · 9df4a607
      Jeff King 提交于
      If certain options like --honor-pack-keep, --local, or
      --incremental are used with pack-objects, then we need to
      feed each potential object to want_object_in_pack() to see
      if it should be filtered out. But when the bitmap
      reuse_packfile optimization is in effect, we do not call
      that function at all, and in fact skip adding the objects to
      the to_pack list entirely.  This means we have a bug: for
      certain requests we will silently ignore those options and
      include objects in that pack that should not be there.
      
      The problem has been present since the inception of the
      pack-reuse code in 6b8fda2d (pack-objects: use bitmaps when
      packing objects, 2013-12-21), but it was unlikely to come up
      in practice.  These options are generally used for on-disk
      packing, not transfer packs (which go to stdout), but we've
      never allowed pack reuse for non-stdout packs (until
      645c432d, we did not even use bitmaps, which the reuse
      optimization relies on; after that, we explicitly turned it
      off when not packing to stdout).
      
      We can fix this by just disabling the reuse_packfile
      optimization when the options are in use. In theory we could
      teach the pack-reuse code to satisfy these checks, but it's
      not worth the complexity. The purpose of the optimization is
      to keep the amount of per-object work we do to a minimum.
      But these options inherently require us to search for other
      copies of each object, drowning out any benefit of the
      pack-reuse optimization. But note that the optimizations
      from 56dfeb62 (pack-objects: compute local/ignore_pack_keep
      early, 2016-07-29) happen before pack-reuse, meaning that
      specifying "--honor-pack-keep" in a repository with no .keep
      files can still follow the fast path.
      
      There are tests in t5310 that check these options with
      bitmaps and --stdout, but they didn't catch the bug, and
      it's hard to adapt them to do so.
      
      One problem is that they don't use --delta-base-offset;
      without that option, we always disable the reuse
      optimization entirely. It would be fine to add it in (it
      actually makes the test more realistic), but that still
      isn't quite enough.
      
      The other problem is that the reuse code is very picky; it
      only kicks in when it can reuse most of a pack, starting
      from the first byte. So we'd have to start from a fully
      repacked and bitmapped state to trigger it. But the tests
      for these options use a much more subtle state; they want to
      be sure that the want_object_in_pack() code is allowing some
      objects but not others. Doing a full repack runs counter to
      that.
      
      So this patch adds new tests at the end of the script which
      create the fully-packed state and make sure that each option
      is not fooled by reusable pack.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9df4a607
  23. 08 5月, 2017 3 次提交
  24. 27 4月, 2017 1 次提交
    • J
      timestamp_t: a new data type for timestamps · dddbad72
      Johannes Schindelin 提交于
      Git's source code assumes that unsigned long is at least as precise as
      time_t. Which is incorrect, and causes a lot of problems, in particular
      where unsigned long is only 32-bit (notably on Windows, even in 64-bit
      versions).
      
      So let's just use a more appropriate data type instead. In preparation
      for this, we introduce the new `timestamp_t` data type.
      
      By necessity, this is a very, very large patch, as it has to replace all
      timestamps' data type in one go.
      
      As we will use a data type that is not necessarily identical to `time_t`,
      we need to be very careful to use `time_t` whenever we interact with the
      system functions, and `timestamp_t` everywhere else.
      Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dddbad72
  25. 31 3月, 2017 4 次提交
  26. 25 3月, 2017 1 次提交