> Martin Fick <mf...@codeaurora.org> writes:
> > * Setup 1:
> >   Do a full repack.  All loose and packed objects are
> >   added
> > * Scenario 1:
> >   Start with Setup 1.  Nothing has changed on the repo
> > contents (no new object/packs, refs all the same), but
> > repacking config options have changed (for example
> > compression level has changed).

On Tuesday, December 03, 2013 10:50:07 am Junio C Hamano 
> Duy Nguyen <pclo...@gmail.com> writes:
> > Reading Martin's mail again I wonder how we just
> > "grab all objects and skip history traversal". Who will
> > decide object order in the new pack if we don't
> > traverse history and collect path information.
> I vaguely recall raising a related topic for "quick
> repack, assuming everything in existing packfiles are
> reachable, that only removes loose cruft" several weeks
> ago.  Once you decide that your quick repack do not care
> about ejecting objects from existing packs, like how I
> suspect Martin's outline will lead us to, we can repack
> the reachable loose ones on the recent surface of the
> history and then concatenate the contents of existing
> packs, excluding duplicates and possibly adjusting the
> delta base offsets for some entries, without traversing
> the bulk of the history.

>From this, it sounds like scenario 1 (a single pack being 
repacked) might then be doable (just trying to establish a 
really simple baseline)?  Except that it would potentially 
not result in the same ordering without traversing history?  
Or, would the current pack ordering be preserved and thus be 


The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to