Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Nov 15, 2008

  1. repack: only unpack-unreachable if we are deleting redundant packs

    The -A option calls pack-objects with the --unpack-unreachable option so
    that the unreachable objects in local packs are left in the local object
    store loose. But if the -d option to repack was _not_ used, then these
    unpacked loose objects are redundant and unnecessary.
    
    Update tests in t7701.
    
    Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Brandon Casey authored gitster committed

Nov 12, 2008

  1. repack: do not fall back to incremental repacking with [-a|-A]

    When repack is called with either the -a or -A option, the user has
    requested to repack all objects including those referenced by the
    alternates mechanism. Currently, if there are no local packs without
    .keep files, then repack will call pack-objects with the
    '--unpacked --incremental' options which causes it to exclude alternate
    packed objects. So, remove this fallback.
    
    Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Brandon Casey authored gitster committed
  2. repack: don't repack local objects in packs with .keep file

    If the user created a .keep file for a local pack, then it can be inferred
    that the user does not want those objects repacked.
    
    This fixes the repack bug tested by t7700.
    
    Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Brandon Casey authored gitster committed

Sep 20, 2008

  1. Mikachu

    git-repack uses --no-repack-object, not --no-repack-delta.

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Mikachu authored gitster committed

Jul 13, 2008

  1. Stephan Beyer

    Make usage strings dash-less

    When you misuse a git command, you are shown the usage string.
    But this is currently shown in the dashed form.  So if you just
    copy what you see, it will not work, when the dashed form
    is no longer supported.
    
    This patch makes git commands show the dash-less version.
    
    For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
    generates a dash-less usage string now.
    
    Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    sbeyer authored gitster committed

Jun 25, 2008

  1. repack.usedeltabaseoffset config option now defaults to "true"

    As announced for 1.6.0.
    
    Access over the native protocol by old git versions is unaffected as
    this capability is negociated by the protocol.  Otherwise setting this
    config option to "false" and doing a 'git repack -a -d' is enough to
    remain compatible with ancient git versions (older than 1.4.4).
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Nicolas Pitre authored gitster committed

May 31, 2008

  1. Linus Torvalds

    Remove now unnecessary 'sync()' calls

    Since the pack-files are now always created stably on disk, there is no
    need to sync() before pruning lose objects or old stale pack-files.
    
    [jc: with Nico's clean-up]
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    torvalds authored gitster committed

May 23, 2008

  1. Junio C Hamano

    Merge branch 'bc/repack'

    * bc/repack:
      Documentation/git-repack.txt: document new -A behaviour
      let pack-objects do the writing of unreachable objects as loose objects
      add a force_object_loose() function
      builtin-gc.c: deprecate --prune, it now really has no effect
      git-gc: always use -A when manually repacking
      repack: modify behavior of -A option to leave unreferenced objects unpacked
    
    Conflicts:
    
    	builtin-pack-objects.c
    gitster authored

May 14, 2008

  1. let pack-objects do the writing of unreachable objects as loose objects

    Commit ccc1297 changed the behavior
    of 'git repack -A' so unreachable objects are stored as loose objects.
    However it did so in a naive and inn efficient way by making packs
    about to be deleted inaccessible and feeding their content through
    'git unpack-objects'.  While this works, there are major flaws with
    this approach:
    
    - It is unacceptably sloooooooooooooow.
    
      In the Linux kernel repository with no actual unreachable objects,
      doing 'git repack -A -d' before:
    
    	real    2m33.220s
    	user    2m21.675s
    	sys     0m3.510s
    
      And with this change:
    
    	real    0m36.849s
    	user    0m24.365s
    	sys     0m1.950s
    
      For reference, here's the timing for 'git repack -a -d':
    
    	real    0m35.816s
    	user    0m22.571s
    	sys     0m2.011s
    
      This is explained by the fact that 'git unpack-objects' was used to
      unpack _every_ objects even if (almost) 100% of them were thrown away.
    
    - There is a black out period.
    
      Between the removal of the .idx file for the redundant pack and the
      completion of its unpacking, the unreachable objects become completely
      unaccessible.  This is not a big issue as we're talking about unreachable
      objects, but some consistency is always good.
    
    - There is no way to easily set a sensible mtime for the newly created
      unreachable loose objects.
    
    So, while having a command called "pack-objects" to perform object
    unpacking looks really odd, this is probably the best compromize to be
    able to solve the above issues in an efficient way.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Nicolas Pitre authored gitster committed

May 11, 2008

  1. Brandon Casey

    repack: modify behavior of -A option to leave unreferenced objects un…

    …packed
    
    The previous behavior of the -A option was to retain any previously
    packed objects which had become unreferenced, and place them into the newly
    created pack file.  Since git-gc, when run automatically with the --auto
    option, calls repack with the -A option, this had the effect of retaining
    unreferenced packed objects indefinitely. To avoid this scenario, the
    user was required to run git-gc with the little known --prune option or
    to manually run repack with the -a option.
    
    This patch changes the behavior of the -A option so that unreferenced
    objects that exist in any pack file being replaced, will be unpacked into
    the repository. The unreferenced loose objects can then be garbage collected
    by git-gc (i.e. git-prune) based on the gc.pruneExpire setting.
    
    Also add new tests for checking whether unreferenced objects which were
    previously packed are properly left in the repository unpacked after
    repacking.
    
    Signed-off-by: Brandon Casey <drafnel@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    drafnel authored gitster committed
  2. A Large Angry SCM

    git-repack: re-enable parsing of -n command line option

    In commit 5715d0b (Migrate git-repack.sh to use git-rev-parse --parseopt,
    2007-11-04), parsing of the '-n' command line option was accidentally lost
    when git-repack.sh was migrated to use git-rev-parse --parseopt. This adds
    it back.
    
    Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitzilla authored gitster committed

Nov 06, 2007

  1. Pierre Habouzit

    Migrate git-repack.sh to use git-rev-parse --parseopt

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    MadCoder authored gitster committed

Oct 19, 2007

  1. Shawn O. Pearce

    Stop displaying "Pack pack-$ID created." during git-gc

    Discussion on the list tonight came to the conclusion that showing
    the name of the packfile we just created during git-repack is not
    a very useful message for any end-user.  For the really technical
    folk who need to have the name of the newest packfile they can use
    something such as `ls -t .git/objects/pack | head -2` to find the
    most recently created packfile.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce authored

Oct 03, 2007

  1. Junio C Hamano

    Merge branch 'jc/autogc'

    * jc/autogc:
      git-gc --auto: run "repack -A -d -l" as necessary.
      git-gc --auto: restructure the way "repack" command line is built.
      git-gc --auto: protect ourselves from accumulated cruft
      git-gc --auto: add documentation.
      git-gc --auto: move threshold check to need_to_gc() function.
      repack -A -d: use --keep-unreachable when repacking
      pack-objects --keep-unreachable
      Export matches_pack_name() and fix its return value
      Invoke "git gc --auto" from commit, merge, am and rebase.
      Implement git gc --auto
    gitster authored

Sep 23, 2007

  1. Supplant the "while case ... break ;; esac" idiom

    A lot of shell scripts contained stuff starting with
    
    	while case "$#" in 0) break ;; esac
    
    and similar.  I consider breaking out of the condition instead of the
    body od the loop ugly, and the implied "true" value of the
    non-matching case is not really obvious to humans at first glance.  It
    happens not to be obvious to some BSD shells, either, but that's
    because they are not POSIX-compliant.  In most cases, this has been
    replaced by a straight condition using "test".  "case" has the
    advantage of being faster than "test" on vintage shells where "test"
    is not a builtin.  Since none of them is likely to run the git
    scripts, anyway, the added readability should be worth the change.
    
    A few loops have had their termination condition expressed
    differently.
    
    Signed-off-by: David Kastrup <dak@gnu.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    David Kastrup authored gitster committed

Sep 18, 2007

  1. Junio C Hamano

    repack -A -d: use --keep-unreachable when repacking

    This is a safer variant of "repack -a -d" that does not drop
    unreachable objects that are in packs.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster authored

Jul 12, 2007

  1. Brian Downing

    Add --window-memory option to git-repack

    Signed-off-by: Brian Downing <bdowning@lavos.net>
    Acked-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    bdowning authored gitster committed

Jul 04, 2007

  1. repack: don't report "Nothing new to pack." if -q is given

    Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Uwe Kleine-König authored gitster committed

Jul 03, 2007

  1. Junio C Hamano

    Rewrite "git-frotz" to "git frotz"

    This uses the remove-dashes target to replace "git-frotz" to "git frotz".
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster authored

May 25, 2007

  1. Ensure git-repack -a -d --max-pack-size=N deletes correct packs

    The packfile portion of the "remove redundant" code
    near the bottom of git-repack.sh is broken when
    pack splitting occurs.  Particularly since this is
    the only place where we automatically delete packfiles,
    make sure it works properly for all cases,  old or new.
    
    Signed-off-by: Dana L. How <danahow@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Dana How authored Junio C Hamano committed

May 21, 2007

  1. git-repack --max-pack-size: add option parsing to enable feature

    Add --max-pack-size parsing and usage messages.
    Upgrade git-repack.sh to handle multiple packfile names,
    and build packfiles in GIT_OBJECT_DIRECTORY not GIT_DIR.
    Update documentation.
    
    Signed-off-by: Dana L. How <danahow@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Dana L. How authored Junio C Hamano committed

May 10, 2007

  1. make "repack -f" imply "pack-objects --no-reuse-object"

    Recomputing delta is much more expensive than recompressing
    anyway, and when the user says 'repack -f', it is a sign that
    the user is willing to spend CPU cycles.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Nicolas Pitre authored Junio C Hamano committed

Jan 29, 2007

  1. Tom Prince

    [PATCH] Rename git-repo-config to git-config.

    Signed-off-by: Tom Prince <tom.prince@ualberta.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    tomprince authored Junio C Hamano committed

Jan 12, 2007

  1. Make git-prune-packed a bit more chatty.

    Steven Grimm noticed that git-repack's verbosity is inconsistent
    because pack-objects is chatty and prune-packed is not.  This
    makes the latter a bit more chatty and gives -q option to
    squelch it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Dec 21, 2006

  1. Teach git-repack to preserve objects referred to by reflog entries.

    This adds a new option --reflog to pack-objects and revision
    machinery; do not bother documenting it for now, since this is
    only useful for local repacking.
    
    When the option is passed, objects reachable from reflog entries
    are marked as interesting while computing the set of objects to
    pack.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Dec 13, 2006

  1. repacked packs should be read-only

    ... just like the other pack creating tools do.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Nicolas Pitre authored Junio C Hamano committed

Oct 29, 2006

  1. Shawn O. Pearce

    Only repack active packs by skipping over kept packs.

    During `git repack -a -d` only repack objects which are loose or
    which reside in an active (a non-kept) pack.  This allows the user
    to keep large packs as-is without continuous repacking and can be
    very helpful on large repositories.  It should also help us resolve
    a race condition between `git repack -a -d` and the new pack store
    functionality in `git-receive-pack`.
    
    Kept packs are those which have a corresponding .keep file in
    $GIT_OBJECT_DIRECTORY/pack.  That is pack-X.pack will be kept
    (not repacked and not deleted) if pack-X.keep exists in the same
    directory when `git repack -a -d` starts.
    
    Currently this feature is not documented and there is no user
    interface to keep an existing pack.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    spearce authored Junio C Hamano committed

Oct 23, 2006

  1. Merge branch 'np/pack'

    * np/pack:
      add the capability for index-pack to read from a stream
      index-pack: compare only the first 20-bytes of the key.
      git-repack: repo.usedeltabaseoffset
      pack-objects: document --delta-base-offset option
      allow delta data reuse even if base object is a preferred base
      zap a debug remnant
      let the GIT native protocol use offsets to delta base when possible
      make pack data reuse compatible with both delta types
      make git-pack-objects able to create deltas with offset to base
      teach git-index-pack about deltas with offset to base
      teach git-unpack-objects about deltas with offset to base
      introduce delta objects with offset to base
    Junio C Hamano authored

Oct 14, 2006

  1. git-repack: repo.usedeltabaseoffset

    When configuration variable `repack.UseDeltaBaseOffset` is set
    for the repository, the command passes `--delta-base-offset`
    option to `git-pack-objects`; this typically results in slightly
    smaller packs, but the generated packs are incompatible with
    versions of git older than (and including) v1.4.3.
    
    We will make it default to true sometime in the future, but not
    for a while.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Sep 25, 2006

  1. Jeff King

    git-repack: allow git-repack to run in subdirectory

    Now that we explicitly create all tmpfiles below $GIT_DIR, there's no reason
    to care about which directory we're in.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    peff authored Junio C Hamano committed

Sep 20, 2006

  1. repack: use only pack-objects, not rev-list.

    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Sep 06, 2006

  1. git-repack: create new packs inside $GIT_DIR, not cwd

    Avoid failing when cwd is !writable by writing the
    packfiles in $GIT_DIR, which is more in line with other commands.
    
    Without this, git-repack was failing when run from crontab
    by non-root user accounts. For large repositories, this
    also makes the mv operation a lot cheaper, and avoids leaving
    temp packfiles around the fs upon failure.
    
    Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Martin Langhoff authored Junio C Hamano committed

Aug 29, 2006

  1. Matthias Kestenholz

    Check if pack directory exists prior to descending into it

    This fixes the following warning:
    
    git-repack: line 42: cd: .git/objects/pack: No such file or directory
    
    This happens only, when git-repack -a is run without any packs in the
    repository.
    
    Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    matthiask authored Junio C Hamano committed

Jul 13, 2006

  1. git-repack: avoid redirecting stderr into git-pack-objects

    We are trying to catch error condition of git-rev-list and cause
    the downstream pack-objects to barf, but if you run rev-list
    with anything that mucks with its stderr (such as GIT_TRACE),
    any stderr output would cause the pipeline to fail.
    
    [jc: originally from Matthias Lederhofer, with a reworded error message.]
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored

Jun 25, 2006

  1. git-repack: Be careful when updating the same pack as an existing one.

    After a clone, packfiles are read-only by default and "mv" to
    replace the pack with a new one goes interactive, asking if the
    user wants to replace it.  If one is successfully moved and the
    other is not, the pack and its idx would become out-of-sync and
    corrupts the repository.
    
    Recovering is straightforward -- it is just the matter of
    finding the remaining .tmp-pack-* and make sure they are both
    moved -- but we should be extra careful not to do something so
    alarming to the users.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    Junio C Hamano authored
Something went wrong with that request. Please try again.