git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Bailey <charles@hashpling.org>
To: "J.C. Pizarro" <jcpiza@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Question about your git habits
Date: Sat, 23 Feb 2008 19:28:58 +0000	[thread overview]
Message-ID: <20080223192858.GA10655@hashpling.org> (raw)
In-Reply-To: <998d0e4a0802231047t1338439cj1a1c98f046e6ebaf@mail.gmail.com>

On Sat, Feb 23, 2008 at 07:47:13PM +0100, J.C. Pizarro wrote:
> On 2008/2/23, Charles Bailey <charles@hashpling.org> wrote:
> > You're confusing two things together here. Conceptually, the git
> >  database is a database of immutable objects. How it is stored is a
> >  lower level implementation detail (albeit a very important one in
> >  practice). The delta chains in the pack files are nothing to do with
> >  git objects.
> 
> In Documentation/git-repack.txt says:
> 
> git-repack is used to combine all objects that do not currently
> reside in a "pack", into a pack. It can also be used to re-organize
> existing packs into a single, more efficient pack.
> 
> A pack is a collection of objects, individually compressed, with
> delta compression applied, stored in a single file, with an
> associated index file.
> 
> ### Can you explain me that delta chains in the pack files are
>  nothing to do with git objects? ###

It's an abstraction thing. Perhaps I should have said that git objects
have nothing to do with pack files to indicate the direction of the
dependency.

> Is not it redundant to place git objects and pack files in the same repo?
> 1. Or erase the unnecesary pack files because there are git objects.
> 2. Or erase some git objects because there are delta chains in pack files
>      that can generate the same git objects erased previously.

Only if they overlap, but usually they don't.

> > What is the weekly user? Why would the 'binary delta' be better than
> >  an incremental pack in this case?
> 
> Because the user wants to clone weekly 240 MiB in 1st week, 220 MiB in
> 2nd week, 205 MiB in 3rd week, .... 100 MiB repo! in Nth week instead of
> 240+1+1+1+1 MiB of incremental packs.
> 
> What is better for the user in the Nth week, 100 MiB repo or 244 MiB repo?
> 

That depends, doesn't it. If the everyday workflow is quicker and
easier a 244 MiB clone could well be acceptable, but if it's not there
is always the option of a repack. I don't buy the premise that people
want to be continually repacking to find the ultimate pack file, I
don't think that the gain over a one-shot repack is ever going to be
worth it.

  reply	other threads:[~2008-02-23 19:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-23  0:37 Question about your git habits Chase Venters
2008-02-23  1:26 ` Tommy Thorn
2008-02-23  1:28 ` Steven Walter
2008-02-23  1:37 ` Jan Engelhardt
2008-02-23  1:44   ` Al Viro
2008-02-23  1:51     ` Junio C Hamano
2008-02-23  2:09       ` Al Viro
     [not found]         ` <998d0e4a0802221823h3ba53097gf64fcc2ea826302b@mail.gmail.com>
2008-02-23  2:47           ` J.C. Pizarro
2008-02-23 11:39             ` Charles Bailey
2008-02-23 13:08               ` J.C. Pizarro
2008-02-23 13:17                 ` Charles Bailey
2008-02-23 13:36                   ` J.C. Pizarro
2008-02-23 14:01                     ` Charles Bailey
2008-02-23 17:10                       ` J.C. Pizarro
2008-02-23 18:16                         ` Charles Bailey
2008-02-23 18:47                           ` J.C. Pizarro
2008-02-23 19:28                             ` Charles Bailey [this message]
2008-02-23 18:19                         ` J.C. Pizarro
2008-02-23 14:08             ` Mike Hommey
2008-02-23  1:42 ` Junio C Hamano
2008-02-23 10:39   ` Samuel Tardieu
     [not found] ` <998d0e4a0802221736q4e4c3a28l101522912f7d3caf@mail.gmail.com>
2008-02-23  2:46   ` J.C. Pizarro
2008-02-23  4:10 ` Daniel Barkalow
2008-02-23  5:03   ` Jeff Garzik
2008-02-23  9:18   ` Mike Hommey
2008-02-23  4:39 ` Rene Herman
2008-02-23  8:56 ` Willy Tarreau
2008-02-23  9:10 ` Sam Ravnborg
2008-02-23 13:07 ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080223192858.GA10655@hashpling.org \
    --to=charles@hashpling.org \
    --cc=git@vger.kernel.org \
    --cc=jcpiza@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).