From: Ted Ts'o <tytso@mit.edu>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Jeff King <peff@peff.net>, Thomas Rast <trast@student.ethz.ch>,
Hallvard B Furuseth <h.b.furuseth@usit.uio.no>,
git@vger.kernel.org
Subject: Re: Keeping unreachable objects in a separate pack instead of loose?
Date: Mon, 11 Jun 2012 13:45:07 -0400 [thread overview]
Message-ID: <20120611174507.GC16086@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1206111249270.23555@xanadu.home>
On Mon, Jun 11, 2012 at 01:04:07PM -0400, Nicolas Pitre wrote:
>
> IIRC, the 2 weeks number was instored when there wasn't any reflog on
> HEAD and the only way to salvage lost commits was to use 'git fsck
> --lost-found'. These days, this is used only as a safety measure
> because there is always a tiny window during which objects are dangling
> before they're finally all referenced as you say. But someone would
> have to work hard to hit that race even if the delay was only 30
> seconds. So realistically this could even be set to 1 hour.
There's another useful part of the two week window, and it's as a
partial workaround using .git/objects/info/alternates with one or more
rewinding branches.
My /usr/projects/e2fsprogs/base repo is a bare repo that contains all
of my public branches, including a rewinding "pu" branch.
My /usr/projects/e2fsprogs/e2fsprogs uses an alternates file to
minimize disk usage, and it points at the base repo.
The problem comes when I need to gc the base repo, every 3 months or
so. When I do that, objects that belonged to older incarnations of
the rewinding pu branch disappear. The two week window gives you a
partial saving throw until development repo breaks due to objects that
it depends upon disappearing.
It would be nice if a gc of the devel repo knew that some of the
objects it was depending on were "expired cruft", and copy them to the
its local objects directory. But of course things don't work that
way.
Here's what I do today (please don't barf; I know it's ugly):
1) cd to the base repository; run "git repack -Adfl --window=300 --depth=100"
2) cd to the objects directory, and create my base "cruft" pack:
find . --name [0-9a-f][0-9a-f] | tr -d / | git pack-objects pack-
3) hard link it into my devel repo's pack directory:
ln pack-* /usr/projects/e2fsprogs/e2fsprogs/.git/objects/pack
4) to save space in my base repo, move it to the pack directory and
run git prune-packed:
mv pack-* pack
git prune-packed
4) run "git repack -Adfl --window=300 --depth=100" in my devel repo
5) create a cruft pack in my devel repo (to save disk space):
cd /usr/projects/e2fsprogs/e2fsprogs/.git/objects
find . --name [0-9a-f][0-9a-f] | tr -d / | git pack-objects pack-
mv pack-* pack
git prune-packed
This probably falls in the "don't use --shared unless you know what it
does admonition in the git-clone man page. :-)
Don't worry, I don't recommend that anyone *else* do this. But it
works for me (although it would be nice if I made this workflow be a
bit more optimized; at the very least I should make a shell script
that does all this for me automatically, instead of typing all of the
shell commands by hand.)
- Ted
next prev parent reply other threads:[~2012-06-11 17:45 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-10 12:31 Keeping unreachable objects in a separate pack instead of loose? Theodore Ts'o
2012-06-10 23:24 ` Hallvard B Furuseth
2012-06-11 14:44 ` Thomas Rast
2012-06-11 15:31 ` Ted Ts'o
2012-06-11 16:08 ` Jeff King
2012-06-11 17:04 ` Nicolas Pitre
2012-06-11 17:45 ` Ted Ts'o [this message]
2012-06-11 17:54 ` Jeff King
2012-06-11 18:20 ` Ted Ts'o
2012-06-11 18:43 ` Jeff King
2012-06-11 17:46 ` Jeff King
2012-06-11 17:27 ` Ted Ts'o
2012-06-11 18:34 ` Jeff King
2012-06-11 20:44 ` Hallvard Breien Furuseth
2012-06-11 21:14 ` Jeff King
2012-06-11 21:41 ` Hallvard Breien Furuseth
2012-06-11 21:14 ` Ted Ts'o
2012-06-11 21:39 ` Jeff King
2012-06-11 22:14 ` Ted Ts'o
2012-06-11 22:23 ` Jeff King
2012-06-11 22:28 ` Ted Ts'o
2012-06-11 22:35 ` Jeff King
2012-06-12 0:41 ` Nicolas Pitre
2012-06-12 17:10 ` Jeff King
2012-06-12 17:30 ` Nicolas Pitre
2012-06-12 17:32 ` Jeff King
2012-06-12 17:45 ` Shawn Pearce
2012-06-12 17:50 ` Jeff King
2012-06-12 17:57 ` Nicolas Pitre
2012-06-12 18:43 ` Andreas Schwab
2012-06-12 19:07 ` Jeff King
2012-06-12 19:09 ` Nicolas Pitre
2012-06-12 19:23 ` Jeff King
2012-06-12 19:39 ` Nicolas Pitre
2012-06-12 19:41 ` Jeff King
2012-06-12 17:55 ` Nicolas Pitre
2012-06-12 17:49 ` Nicolas Pitre
2012-06-12 17:54 ` Jeff King
2012-06-12 18:25 ` Nicolas Pitre
2012-06-12 18:37 ` Ted Ts'o
2012-06-12 19:15 ` Nicolas Pitre
2012-06-12 19:19 ` Ted Ts'o
2012-06-12 19:35 ` Nicolas Pitre
2012-06-12 19:43 ` Ted Ts'o
2012-06-12 19:15 ` Jeff King
2012-06-13 18:17 ` Martin Fick
2012-06-13 21:27 ` Johan Herland
2012-06-11 15:40 ` Junio C Hamano
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=20120611174507.GC16086@thunk.org \
--to=tytso@mit.edu \
--cc=git@vger.kernel.org \
--cc=h.b.furuseth@usit.uio.no \
--cc=nico@fluxnic.net \
--cc=peff@peff.net \
--cc=trast@student.ethz.ch \
/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).