From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:25
"Josh Boyer" [off-list ref] writes:
I was playing around with git repack and decided to "undo" the repack
I did using git-unpack objects. Below is the output:
[jwboyer@vader linux-2.6]$ git-unpack-objects <
.git/objects/pack/pack-497d1e639572013de48eeb00cb95738d2ca959e1.pack
Unpacking 236950 objects
100% (236950/236950) done
[jwboyer@vader linux-2.6]$ ls -l .git/objects/
total 8
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 info
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 pack
[jwboyer@vader linux-2.6]$
As you can see, the objects don't seem to get unpacked back into the
.git directory. So either I am misunderstanding what that command is
supposed to do, or it isn't working properly.
Any ideas?
unpack tries to unpack and if it already has the object it
skips.
If you really wanted to do it, here is a way to do so.
mv .git/objets/pack/pack-49*.pack \
.git/objets/pack/pack-49*.idx .
git unpack-objects <pack-49*.pack
unpack tries to unpack and if it already has the object it
skips.
If you really wanted to do it, here is a way to do so.
mv .git/objets/pack/pack-49*.pack \
.git/objets/pack/pack-49*.idx .
git unpack-objects <pack-49*.pack
Hm.. so it seems that git-unpack-objects is more intended to unpack a
pack one has gotten with git-fetch-pack, right?
I was looking for something more along the lines of an
"un-git-repack", where you have existing pack(s) and want to undo
them. Maybe you want to repack everything into a single pack or
something like that.
josh
Hm.. so it seems that git-unpack-objects is more intended to unpack a
pack one has gotten with git-fetch-pack, right?
Yeah. And for testing. I don't think it ever gets used directly.
I was looking for something more along the lines of an
"un-git-repack", where you have existing pack(s) and want to undo
them. Maybe you want to repack everything into a single pack or
something like that.
That's what you just do "git repack -a -d" for.
Linus
Hm.. so it seems that git-unpack-objects is more intended to unpack a
pack one has gotten with git-fetch-pack, right?
Yeah. And for testing. I don't think it ever gets used directly.
quoted
I was looking for something more along the lines of an
"un-git-repack", where you have existing pack(s) and want to undo
them. Maybe you want to repack everything into a single pack or
something like that.
That's what you just do "git repack -a -d" for.
But that doesn't roll exsisting packs into a new pack, does it? I
thought it just packed loose objects into a new pack and deleted them.
I ran that on a repo that already had a couple packs in it, and the
old packs were still there.
josh
But that doesn't roll exsisting packs into a new pack, does it?
It does. That's what the "-a" (for "all") does.
I don't personally do incremental packs at all - the full repack is fast
enough on the hardware I use (especially since Junio just kicked it into
some serious performance shape) that I don't have the need for
incrementals.
Linus
But that doesn't roll exsisting packs into a new pack, does it?
It does. That's what the "-a" (for "all") does.
Odd. On one of my repos, I was seeing the correct behavior. On
another, there were multiple packs left after doing the 'git repack -a
-d'. Were there ever some packing bugs in older versions of git that
would have maybe produced some packs that wouldn't get deleted or
something?
At any rate, the above command does seem to do exactly what I want.
Thanks for the help.
josh
From: Marco Roeland <hidden> Date: 2016-06-15 22:42:25
On Wednesday May 3rd 2006 Josh Boyer wrote:
quoted
It does. That's what the "-a" (for "all") does.
Odd. On one of my repos, I was seeing the correct behavior. On
another, there were multiple packs left after doing the 'git repack -a
-d'. Were there ever some packing bugs in older versions of git that
would have maybe produced some packs that wouldn't get deleted or
something?
Have you checked with "git fsck-objects" that maybe the "remaining"
packs contained non-reachable objects like dangling commits from resets
or from following volatile branches like +pu?
--
Marco Roeland
Odd. On one of my repos, I was seeing the correct behavior. On
another, there were multiple packs left after doing the 'git repack -a
-d'. Were there ever some packing bugs in older versions of git that
would have maybe produced some packs that wouldn't get deleted or
something?
Have you checked with "git fsck-objects" that maybe the "remaining"
packs contained non-reachable objects like dangling commits from resets
or from following volatile branches like +pu?
This was on a kernel repo, so no branches. But dangling commits from
resets might have been present. I can't tell now since I undid all
that packs and redid them into a single. Thanks for the suggestion
though, that sounds like a perfectly reasonable explanation.
josh