1. 16 Apr, 2019 1 commit
    • Jeff King's avatar
      pack-revindex: open index if necessary · 4828ce98
      Jeff King authored
      We can't create a pack revindex if we haven't actually looked at the
      index. Normally we would never get as far as creating a revindex without
      having already been looking in the pack, so this code never bothered to
      double-check that pack->index_data had been loaded.
      
      But with the new multi-pack-index feature, many code paths might not
      load the individual pack .idx at all (they'd find objects via the midx
      and then open the .pack, but not its index).
      
      This can't yet be triggered in practice, because a bug in the midx code
      means we accidentally open up the individual .idx files anyway. But in
      preparation for fixing that, let's have the revindex code check that
      everything it needs has been loaded.
      
      In most cases this will just be a quick noop. But note that this does
      introduce a possibility of error (if we have to open the index and it's
      corrupt), so load_pack_revindex() now returns a result code, and callers
      need to handle the error.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      4828ce98
  2. 21 Dec, 2015 1 commit
    • Jeff King's avatar
      pack-revindex: store entries directly in packed_git · 9d98bbf5
      Jeff King authored
      A pack_revindex struct has two elements: the revindex
      entries themselves, and a pointer to the packed_git. We need
      both to do lookups, because only the latter knows things
      like the number of objects in the pack.
      
      Now that packed_git contains the pack_revindex struct it's
      just as easy to pass around the packed_git itself, and we do
      not need the extra back-pointer.
      
      We can instead just store the entries directly in the pack.
      All functions which took a pack_revindex now just take a
      packed_git. We still lazy-load in find_pack_revindex, so
      most callers are unaffected.
      
      The exception is the bitmap code, which computes the
      revindex and caches the pointer when we load the bitmaps. We
      can continue to load, drop the extra cache pointer, and just
      access bitmap_git.pack.revindex directly.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      9d98bbf5
  3. 16 Jan, 2014 1 commit
    • Jeff King's avatar
      do not discard revindex when re-preparing packfiles · 1a6d8b91
      Jeff King authored
      When an object lookup fails, we re-read the objects/pack
      directory to pick up any new packfiles that may have been
      created since our last read. We also discard any pack
      revindex structs we've allocated.
      
      The discarding is a problem for the pack-bitmap code, which keeps
      a pointer to the revindex for the bitmapped pack. After the
      discard, the pointer is invalid, and we may read free()d
      memory.
      
      Other revindex users do not keep a bare pointer to the
      revindex; instead, they always access it through
      revindex_for_pack(), which lazily builds the revindex. So
      one solution is to teach the pack-bitmap code a similar
      trick. It would be slightly less efficient, but probably not
      all that noticeable.
      
      However, it turns out this discarding is not actually
      necessary. When we call reprepare_packed_git, we do not
      throw away our old pack list. We keep the existing entries,
      and only add in new ones. So there is no safety problem; we
      will still have the pack struct that matches each revindex.
      The packfile itself may go away, of course, but we are
      already prepared to handle that, and it may happen outside
      of reprepare_packed_git anyway.
      
      Throwing away the revindex may save some RAM if the pack
      never gets reused (about 12 bytes per object). But it also
      wastes some CPU time (to regenerate the index) if the pack
      does get reused. It's hard to say which is more valuable,
      but in either case, it happens very rarely (only when we
      race with a simultaneous repack). Just leaving the revindex
      in place is simple and safe both for current and future
      code.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      1a6d8b91
  4. 24 Oct, 2013 1 commit
  5. 23 Aug, 2008 1 commit
  6. 24 Jun, 2008 1 commit
  7. 01 Mar, 2008 1 commit