From: Sivakumar Selvam <gerritcode@gmail.com>
To: git@vger.kernel.org
Subject: Re: git repack command on larger pack file
Date: Tue, 27 Oct 2015 02:04:23 +0000 (UTC) [thread overview]
Message-ID: <loom.20151027T025257-333@post.gmane.org> (raw)
In-Reply-To: xmqqziz6hzom.fsf@gitster.mtv.corp.google.com
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Junio C Hamano <gitster <at> pobox.com> writes:
>
> > Sivakumar Selvam <gerritcode <at> gmail.com> writes:
> >
> >> ... So
> >> I thought of splitting the pack file into 4 GB chunks.
> > ...
> > Hmmm, what is "this issue"? I do not see anything surprising.
>
> While the explanation might have been enlightening, the knowledge
> conveyed by the explanation by itself would not be of much practical
> use, and enlightment without practical use is never fun.
>
> So let's do another tangent that may be more useful.
>
> In many repositories, older parts of the history often hold the bulk
> of objects that do not change, and it is wasteful to repack them
> over and over. If your project is at around v40.0 today, and it was
> at around v36.0 6 months ago, for example, you may want to pack
> everything that happened before v36.0 into a single pack just once,
> pack them really well, and have your "repack" not touch that old
> part of the history.
>
> $ git rev-list --objects v36.0 |
> git pack-objects --window=200 --depth=128 pack
>
> would produce such a pack [*1*]
>
> The standard output from the above pipeline will give you a 40-hex
> string (e.g. 51c472761b4690a331c02c90ec364e47cca1b3ac, call it
> $HEX), and in the current directory you will find two files,
> pack-$HEX.pack and pack-$HEX.idx.
>
> You can then do this:
>
> $ echo "v36.0 with W/D 200/128" >pack-$HEX.keep
> $ mv pack-$HEX.* .git/objects/pack/.
> $ git repack -a -d
>
> A pack that has an accompanying .keep file is excempt from
> repacking, so once you do this, your future "git repack" will only
> repack objects that are not in the kept packs.
>
> [Footnote]
>
> *1* I won't say 200/128 gives you a good pack; you would need to
> experiment. In general, larger depth will result in smaller pack
> but it will result in bigger overhead while you use the repository
> every day. Larger window will spend a lot of cycles while packing,
> but will result in a smaller pack.
>
Hi Junio,
When I finished git repacking, I found 12 pack files with each 4 GB and
the total size is 48 GB. Again I ran the same git repack command by just
removing only --max-pack-size= parameter, the size of the single pack file
is 66 GB.
git repack -A -b -d -q --depth=50 --window=10 abc.git
Now, I see the total size of the single abc.git has become 66 GB. Initially
it was 34 GB, After using --max-pack-size=4g it become 48 GB. When we
remove the --max-pack-size=4g parameter and tried to create a single pack
file now it become 66 GB.
Looks like once we do git repack with multiple pack files, we can't revert
back to the original size.
Thanks,
Sivakumar Selvam.
next prev parent reply other threads:[~2015-10-27 2:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 5:57 git repack command on larger pack file Sivakumar Selvam
2015-10-26 6:41 ` Junio C Hamano
2015-10-26 7:11 ` Junio C Hamano
2015-10-27 2:04 ` Sivakumar Selvam [this message]
2015-10-27 23:44 ` Jeff King
2015-10-28 6:23 ` Junio C Hamano
2015-10-28 6:47 ` Junio C Hamano
2015-10-27 8:52 ` Philip Oakley
2015-10-27 23:47 ` Jeff King
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=loom.20151027T025257-333@post.gmane.org \
--to=gerritcode@gmail.com \
--cc=git@vger.kernel.org \
/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).