Skip to content
Commits on Nov 30, 2011
  1. @gitster

    csum-file: introduce sha1file_checkpoint

    gitster committed Nov 17, 2011
    It is useful to be able to rewind a check-summed file to a certain
    previous state after writing data into it using sha1write() API. The
    fast-import command does this after streaming a blob data to the packfile
    being generated and then noticing that the same blob has already been
    written, and it does this with a private code truncate_pack() that is
    commented as "Yes, this is a layering violation".
    Introduce two API functions, sha1file_checkpoint(), that allows the caller
    to save a state of a sha1file, and then later revert it to the saved state.
    Use it to reimplement truncate_pack().
    Signed-off-by: Junio C Hamano <>
Commits on Feb 28, 2011
  1. @gitster

    index-pack: --verify

    gitster committed Feb 2, 2011
    Given an existing .pack file and the .idx file that describes it,
    this new mode of operation reads and re-index the packfile and makes
    sure the existing .idx file matches the result byte-for-byte.
    All the objects in the .pack file are validated during this operation as
    well.  Unlike verify-pack, which visits each object described in the .idx
    file in the SHA-1 order, index-pack efficiently exploits the delta-chain
    to avoid rebuilding the objects that are used as the base of deltified
    objects over and over again while validating the objects, resulting in
    much quicker verification of the .pack file and its .idx file.
    This version however cannot verify a .pack/.idx pair with a handcrafted v2
    index that uses 64-bit offset representation for offsets that would fit
    within 31-bit. You can create such an .idx file by giving a custom offset
    to --index-version option to the command.
    Signed-off-by: Junio C Hamano <>
Commits on Oct 10, 2008
  1. @spearce

    Merge branch 'maint'

    spearce committed Oct 10, 2008
    * maint:
      rebase -i: do not fail when there is no commit to cherry-pick
      test-lib: fix color reset in say_color()
      fix pread()'s short read in index-pack
  2. @spearce

    fix pread()'s short read in index-pack

    Nicolas Pitre committed with spearce Oct 9, 2008
    Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
    its ability to compute a SHA1 on the written data.  This also provides
    data buffering which, along with commit 92392b4, will confuse pread()
    whenever an appended object is 1) freed due to memory pressure because
    of the depth-first delta processing, and 2) needed again because it has
    many delta children, and 3) its data is still buffered by sha1write().
    Let's fix the issue by simply forcing cached data out when such an
    object is written so it can be pread()'d at leisure.
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Shawn O. Pearce <>
Commits on Oct 3, 2008
  1. @spearce

    fix openssl headers conflicting with custom SHA1 implementations

    Nicolas Pitre committed with spearce Oct 1, 2008
    On ARM I have the following compilation errors:
        CC fast-import.o
    In file included from cache.h:8,
                     from builtin.h:6,
                     from fast-import.c:142:
    arm/sha1.h:14: error: conflicting types for 'SHA_CTX'
    /usr/include/openssl/sha.h:105: error: previous declaration of 'SHA_CTX' was here
    arm/sha1.h:16: error: conflicting types for 'SHA1_Init'
    /usr/include/openssl/sha.h:115: error: previous declaration of 'SHA1_Init' was here
    arm/sha1.h:17: error: conflicting types for 'SHA1_Update'
    /usr/include/openssl/sha.h:116: error: previous declaration of 'SHA1_Update' was here
    arm/sha1.h:18: error: conflicting types for 'SHA1_Final'
    /usr/include/openssl/sha.h:117: error: previous declaration of 'SHA1_Final' was here
    make: *** [fast-import.o] Error 1
    This is because openssl header files are always included in
    git-compat-util.h since commit 684ec6c whenever NO_OPENSSL is not
    set, which somehow brings in <openssl/sha1.h> clashing with the custom
    ARM version.  Compilation of git is probably broken on PPC too for the
    same reason.
    Turns out that the only file requiring openssl/ssl.h and openssl/err.h
    is imap-send.c.  But only moving those problematic includes there
    doesn't solve the issue as it also includes cache.h which brings in the
    conflicting local SHA1 header file.
    As suggested by Jeff King, the best solution is to rename our references
    to SHA1 functions and structure to something git specific, and define those
    according to the implementation used.
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Shawn O. Pearce <>
Commits on May 31, 2008
  1. @torvalds @gitster

    Make pack creation always fsync() the result

    torvalds committed with gitster May 30, 2008
    This means that we can depend on packs always being stable on disk,
    simplifying a lot of the object serialization worries.  And unlike loose
    objects, serializing pack creation IO isn't going to be a performance
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 5, 2007
  1. @gitster

    remove dead code from the csum-file interface

    Nicolas Pitre committed with gitster Nov 4, 2007
    The provided name argument is always constant and valid in every
    caller's context, so no need to have an array of PATH_MAX chars to copy
    it into when a simple pointer will do.  Unfortunately that means getting
    rid of wascally wabbits too.
    The 'error' field is also unused.
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Junio C Hamano <>
  2. @gitster

    make display of total transferred more accurate

    Nicolas Pitre committed with gitster Nov 4, 2007
    The throughput display needs a delay period before accounting and
    displaying anything.  Yet it might be called after some amount of data
    has already been transferred.  The display of total data is therefore
    accounted late and therefore smaller than the reality.
    Let's call display_throughput() with an absolute amount of transferred
    data instead of a relative number, and let the throughput code find the
    relative amount of data by itself as needed.  This way the displayed
    total is always exact.
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 30, 2007
  1. @gitster

    add throughput display to git-push

    Nicolas Pitre committed with gitster Oct 30, 2007
    This one triggers only when git-pack-objects is called with
    --all-progress and --stdout which is the combination used by
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Junio C Hamano <>
Commits on Jun 13, 2007
  1. @gitster

    More static

    gitster committed Jun 13, 2007
    There still are quite a few symbols that ought to be static.
    Signed-off-by: Junio C Hamano <>
Commits on May 10, 2007
  1. Custom compression levels for objects and packs

    Dana How committed with Junio C Hamano May 9, 2007
    Add config variables pack.compression and core.loosecompression ,
    and switch --compression=level to pack-objects.
    Loose objects will be compressed using core.loosecompression if set,
    else core.compression if set, else Z_BEST_SPEED.
    Packed objects will be compressed using --compression=level if seen,
    else pack.compression if set, else core.compression if set,
    else Z_DEFAULT_COMPRESSION.  This is the "pack compression level".
    Loose objects added to a pack undeltified will be recompressed
    to the pack compression level if it is unequal to the current
    loose compression level by the preceding rules,  or if the loose
    object was written while core.legacyheaders = true.  Newly
    deltified loose objects are always compressed to the current
    pack compression level.
    Previously packed objects added to a pack are recompressed
    to the current pack compression level exactly when their
    deltification status changes,  since the previous pack data
    cannot be reused.
    In either case,  the --no-reuse-object switch from the first
    patch below will always force recompression to the current pack
    compression level,  instead of assuming the pack compression level
    hasn't changed and pack data can be reused when possible.
    This applies on top of the following patches from Nicolas Pitre:
    [PATCH] allow for undeltified objects not to be reused
    [PATCH] make "repack -f" imply "pack-objects --no-reuse-object"
    Signed-off-by: Dana L. How <>
    Signed-off-by: Junio C Hamano <>
Commits on Apr 10, 2007
  1. compute a CRC32 for each object as stored in a pack

    Nicolas Pitre committed with Junio C Hamano Apr 9, 2007
    The most important optimization for performance when repacking is the
    ability to reuse data from a previous pack as is and bypass any delta
    or even SHA1 computation by simply copying the raw data from one pack
    to another directly.
    The problem with  this is that any data corruption within a copied object
    would go unnoticed and the new (repacked) pack would be self-consistent
    with its own checksum despite containing a corrupted object.  This is a
    real issue that already happened at least once in the past.
    In some attempt to prevent this, we validate the copied data by inflating
    it and making sure no error is signaled by zlib.  But this is still not
    perfect as a significant portion of a pack content is made of object
    headers and references to delta base objects which are not deflated and
    therefore not validated when repacking actually making the pack data reuse
    still not as safe as it could be.
    Of course a full SHA1 validation could be performed, but that implies
    full data inflating and delta replaying which is extremely costly, which
    cost the data reuse optimization was designed to avoid in the first place.
    So the best solution to this is simply to store a CRC32 of the raw pack
    data for each object in the pack index.  This way any object in a pack can
    be validated before being copied as is in another pack, including header
    and any other non deflated data.
    Why CRC32 instead of a faster checksum like Adler32?  Quoting Wikipedia:
       Jonathan Stone discovered in 2001 that Adler-32 has a weakness for very
       short messages. He wrote "Briefly, the problem is that, for very short
       packets, Adler32 is guaranteed to give poor coverage of the available
       bits. Don't take my word for it, ask Mark Adler. :-)" The problem is
       that sum A does not wrap for short messages. The maximum value of A for
       a 128-byte message is 32640, which is below the value 65521 used by the
       modulo operation. An extended explanation can be found in RFC 3309,
       which mandates the use of CRC32 instead of Adler-32 for SCTP, the
       Stream Control Transmission Protocol.
    In the context of a GIT pack, we have lots of small objects, especially
    deltas, which are likely to be quite small and in a size range for which
    Adler32 is dimed not to be sufficient.  Another advantage of CRC32 is the
    possibility for recovery from certain types of small corruptions like
    single bit errors which are the most probable type of corruptions.
    OK what this patch does is to compute the CRC32 of each object written to
    a pack within pack-objects.  It is not written to the index yet and it is
    obviously not validated when reusing pack data yet either.
    Signed-off-by: Nicolas Pitre <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 10, 2005
  1. @sirainen

    [PATCH] -Werror fixes

    sirainen committed with Junio C Hamano Aug 9, 2005
    GCC's format __attribute__ is good for checking errors, especially
    with -Wformat=2 parameter. This fixes most of the reported problems
    against 2005-08-09 snapshot.
Commits on Jun 28, 2005
  1. csum-file: add "sha1fd()" to create a SHA1 csum file from an existing…

    Linus Torvalds committed Jun 28, 2005
    … file descriptor
    We'll use this soon to write pack-files to stdout.
Commits on Jun 27, 2005
  1. csum-file interface updates: return resulting SHA1

    Linus Torvalds committed Jun 26, 2005
    Also, make the writing of the SHA1 as a end-header be conditional: not
    every user will necessarily want to write the SHA1 to the file itself,
    even though current users do (but we migh end up using the same helper
    functions for the object files themselves, that don't do this).
    This also makes the packed index file contain the SHA1 of the packed
    data file at the end (just before its own SHA1).  That way you can
    validate the pairing of the two if you want to.
  2. git-pack-objects: write the pack files with a SHA1 csum

    Linus Torvalds committed Jun 26, 2005
    We want to be able to check their integrity later, and putting the
    sha1-sum of the contents at the end is a good thing.  The writing
    routines are generic, so we could try to re-use them for the index file,
    instead of having the same logic duplicated.
    Update unpack-objects to know about the extra 20 bytes at the end
    of the index.
Something went wrong with that request. Please try again.