git gc & deleted branches

[gc]
reflogExpire = 0
reflogExpireUnreachable = 0
rerereresolved = 0
rerereunresolved = 0
packrefs = 1

I also tried 'git-pack-refs --all' or 'git-pack-refs --prune' but to no avail.

Quoted 6 lines · Guido Ostkamp

[gc]
reflogExpire = 0
reflogExpireUnreachable = 0
rerereresolved = 0
rerereunresolved = 0
packrefs = 1

git-gc uses a "safe" pruning mode, where it only prunes unreferenced objects that are older than a certain period (this makes it safe to run git-gc, even if other processes are creating objects at the same time).

So try

[gc]
pruneExpire = now

Alternatively, you can just run 'git prune' manually instead of 'git gc'.

Jeff, I tried it, but it has no effect (see below). There is only the master branch left, and only one commit therein, still it uses the space former occupied by the branch. I'm using git version 1.5.5.1.147.g867f.

Quoted 18 lines · Jeff King

Quoted 6 lines · Guido Ostkamp

[gc]
reflogExpire = 0
reflogExpireUnreachable = 0
rerereresolved = 0
rerereunresolved = 0
packrefs = 1

git-gc uses a "safe" pruning mode, where it only prunes unreferenced objects that are older than a certain period (this makes it safe to run git-gc, even if other processes are creating objects at the same time).

So try

[gc]
pruneExpire = now

Quoted 2 lines

Alternatively, you can just run 'git prune' manually instead of 'git gc'.

Jeff, I tried it, but it has no effect (see below). There is only the master branch left, and only one commit therein, still it uses the space former occupied by the branch. I'm using git version 1.5.5.1.147.g867f.

Any further ideas?

btw, this is _really_ a non-issue. It seems to keep coming up on the list.

Just know that each one of the config options that you set to zero, including the one Jeff suggested setting to "now", is a safety mechanism that is there to ensure that you never ever lose data and that mistakes are recoverable.

Possibly that object got packed? git-prune only removes loose objects. Try 'git gc --prune' which will call git-repack with the -a option.

Just know that each one of the config options that you set to zero, including the one Jeff suggested setting to "now", is a safety mechanism that is there to ensure that you never ever lose data and that mistakes are recoverable.

And be assured that the objects referenced by a deleted branch will be removed from the repository eventually as long as 'git gc --prune' is run periodically.

Quoted 3 lines

And be assured that the objects referenced by a deleted branch will be removed from the repository eventually as long as 'git gc --prune' is run periodically.

Ok. I did not know about the 'prune' option yet as it neither mentioned in the "Git Tutorial" nor "Everyday Git", there only 'git gc' is used with no options.

Quoted 7 lines · Guido Ostkamp

Quoted 3 lines

And be assured that the objects referenced by a deleted branch will be removed from the repository eventually as long as 'git gc --prune' is run periodically.

Ok. I did not know about the 'prune' option yet as it neither mentioned in the "Git Tutorial" nor "Everyday Git", there only 'git gc' is used with no options.

It is deprecated; see 25ee9731.

According to that commit message, prune is now a no-op. However, it looks like it is still used for trigger a "repack -a" rather than "repack -A". I don't know if it is worth making that behavior available through some more sane command line option (I would think people who really know that they want "repack -a" would just call it).

Quoted 3 lines

According to that commit message, prune is now a no-op. However, it looks like it is still used for trigger a "repack -a" rather than "repack -A". I don't know if it is worth making that behavior available

Well, actually this is a problem.

I think it is a good thing to deprecate gc --prune. but if that means that repack -a is never used then unreferenced and expired objects will never be pruned if they're packed if one is always using 'git gc' as we are advocating.

Quoted 5 lines · Nicolas Pitre

Quoted 3 lines

According to that commit message, prune is now a no-op. However, it looks like it is still used for trigger a "repack -a" rather than "repack -A". I don't know if it is worth making that behavior available

Well, actually this is a problem.

Quoted 4 lines

I think it is a good thing to deprecate gc --prune. but if that means that repack -a is never used then unreferenced and expired objects will never be pruned if they're packed if one is always using 'git gc' as we are advocating.

I thought that -A would eventually put them all into a single pack, killing off the old packs.

Quoted 2 lines

I thought that -A would eventually put them all into a single pack, killing off the old packs.

'-a' puts everything in a single pack and kills off old packs. Anything that was unreachable is not repacked in the new pack.

'-A' does the same thing but it also repacks the unreachable objects that were previously packed.

Quoted 5 lines · Brandon Casey

Quoted 2 lines

I thought that -A would eventually put them all into a single pack, killing off the old packs.

'-a' puts everything in a single pack and kills off old packs. Anything that was unreachable is not repacked in the new pack.

Quoted 2 lines

'-A' does the same thing but it also repacks the unreachable objects that were previously packed.

Ah, indeed. I hadn't looked closely at the -A behavior before. So yes, we are never killing off prunable packed objects. Probably we could use the same solution as "git prune --expire"; perhaps a "--keep-unreachable=2.weeks.ago"?

The 'prune --expire' behavior is based on object mtime (i.e. file modification time). That is lost once something is packed right?

I was thinking that either repack or pack-objects could be modified to unpack those unreachable objects and leave them loose, and also give them the timestamp of the pack file they came from. Then the --expire behavior of git-prune could work normally and remove them. This seems like it would work nicely since prune follows repack in git-gc.

Quoted 2 lines · Brandon Casey

The 'prune --expire' behavior is based on object mtime (i.e. file modification time). That is lost once something is packed right?

Yes. You would have to use the pack mtime. But of course you would have to actually _leave_ them in a pack, or they would just keep getting added to the new pack.

Quoted 3 lines

Yes. You would have to use the pack mtime. But of course you would have to actually _leave_ them in a pack, or they would just keep getting added to the new pack.

I had the impression that unreachable objects would not be packed. Maybe it was more of an assumption.

Quoted 4 lines · Brandon Casey

Quoted 3 lines

Yes. You would have to use the pack mtime. But of course you would have to actually _leave_ them in a pack, or they would just keep getting added to the new pack.

Quoted 2 lines

I had the impression that unreachable objects would not be packed. Maybe it was more of an assumption.

Look in builtin-pack-objects.c:1981-1982. We basically just say "if it's in a pack now, then it should go into the new pack."

-Peff

git-repack.sh +9 -1

-       rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
+       rm -f "$PACKDIR/old-pack-$name.idx"
+       test -z "$keep_unreachable" ||
+         ! test -f "$PACKDIR/old-pack-$name.pack" ||
+         git unpack-objects < "$PACKDIR/old-pack-$name.pack" || {
+               echo >&2 "Failed unpacking unreachable objects from old pack"
+               echo >&2 "saved as old-pack-$name.pack in $PACKDIR."
+               exit 1
+       }
+       rm -f "$PACKDIR/old-pack-$name.pack"
[...]

Is the first invocation of unpack-objects necessary? pack-objects has created a pack which hashes to the same name of a pack we already have, and we replace the original with the new one. Is that what is happening? They will be identical right?

Of course this won't set the timestamp on the created objects based on the timestamp of the pack file, but this was easy. Setting the timestamp would be proper, but what's another two weeks. Besides, for those users not manually running git-gc, this code path won't even be executed until there are enough pack files for git-gc to add -A to the repack options.

I like it. It makes an easy rule to say "packed objects _never_ get pruned, they only get demoted to loose objects." And then of course we have sane rules for pruning loose objects.

Quoted 3 lines · Jeff King

I like it. It makes an easy rule to say "packed objects _never_ get pruned, they only get demoted to loose objects." And then of course we have sane rules for pruning loose objects.

Isn't there an issue with the "git gc" triggering because there may be too many loose unreferenced objects?
Still, I do like the approach.

Maybe unreferenced objects and old refs should go to a .git/lost+found directory and be expired from there. This has a couple of benefits:

- Objects will not be accessible by ordinary git commands for a while, before they are really removed, avoiding surprises

Quoted 2 lines

- Objects will not be accessible by ordinary git commands for a while, before they are really removed, avoiding surprises

Unreferenced objects are sometimes used by other repositories which have this repository listed as an alternate. So it may not be a good idea to make the unreferenced objects inaccessible.

Quoted 5 lines · Brandon Casey

Quoted 2 lines

- Objects will not be accessible by ordinary git commands for a while, before they are really removed, avoiding surprises

Unreferenced objects are sometimes used by other repositories which have this repository listed as an alternate. So it may not be a good idea to make the unreferenced objects inaccessible.

But that is precisely what we're going to do, but in two weeks. Isn't it better to have the dependent repo fail while the change is recoverable?

Quoted 7 lines · Geert Bosch

Quoted 3 lines · Jeff King

I like it. It makes an easy rule to say "packed objects _never_ get pruned, they only get demoted to loose objects." And then of course we have sane rules for pruning loose objects.

Quoted 3 lines

Isn't there an issue with the "git gc" triggering because there may be too many loose unreferenced objects?
Still, I do like the approach.

This would be an argument for going the extra mile and having the loose objects adopt the timestamp of their pack file. In the normal case they would probably be pruned immediately during the same git-gc run.

Quoted 5 lines

Maybe unreferenced objects and old refs should go to a .git/lost+found directory and be expired from there. This has a couple of benefits:

- Objects will not be accessible by ordinary git commands for a while, before they are really removed, avoiding surprises

Unreferenced objects are sometimes used by other repositories which have this repository listed as an alternate. So it may not be a good idea to make the unreferenced objects inaccessible.

Quoted 6 lines · Brandon Casey

Quoted 5 lines · Geert Bosch

Quoted 3 lines · Jeff King

I like it. It makes an easy rule to say "packed objects _never_ get pruned, they only get demoted to loose objects." And then of course we have sane rules for pruning loose objects.

Quoted 6 lines

Quoted 3 lines

Isn't there an issue with the "git gc" triggering because there may be too many loose unreferenced objects?
Still, I do like the approach.

This would be an argument for going the extra mile and having the loose objects adopt the timestamp of their pack file. In the normal case they would probably be pruned immediately during the same git-gc run.

Well, not necessarily. If you created a large branch yesterday and you are deleting it today, then if you repacked in between means that those loose objects won't be more than one day old. Yet there could be enough of them to trigger auto gc. But that auto gc won't pack those objects since they are unreferenced. Hence auto gc will trigger all the time without making any progress.

Quoted 3 lines · Brandon Casey

Unreferenced objects are sometimes used by other repositories which have this repository listed as an alternate. So it may not be a good idea to make the unreferenced objects inaccessible.

Nah. If this is really the case then you shouldn't be running gc at all in the first place.

I think the true motivation behind --keep-unreachable is not about the shared object store (aka "alternates") but about races between gc and push (or fetch). Before push (or fetch) finishes and updates refs, the new objects they create would be dangling _and_ the objects these dangling objects refer to may be packed but unreferenced. Repacking unreferenced packed objects was a way to avoid losing them.

From 443b1201d54f0b7197d18779ce934823e9897b36 Mon Sep 17 00:00:00 2001

Quoted 8 lines · Nicolas Pitre

Quoted 3 lines · Brandon Casey

Unreferenced objects are sometimes used by other repositories which have this repository listed as an alternate. So it may not be a good idea to make the unreferenced objects inaccessible.

Nah. If this is really the case then you shouldn't be running gc at all in the first place.

True.

I think the true motivation behind --keep-unreachable is not about the shared object store (aka "alternates") but about races between gc and push (or fetch). Before push (or fetch) finishes and updates refs, the new objects they create would be dangling _and_ the objects these dangling objects refer to may be packed but unreferenced. Repacking unreferenced packed objects was a way to avoid losing them.

It is extremely cumbersome to have to worry about whether there are other concurrent accesses to the repository when running e.g. git gc. For servers, you may never be able to guarantee that nothing else is accessing the repository concurrently. Here is a possible solution:

Each git process creates a log file of the references that it has created. The log file should be named in some way with e.g. the process id and start time of the process, and simply consist of a list of 20-byte sha1 hashes to be considered additional in-use references for the purpose of garbage collection.

Quoted 10 lines · Jeremy Maitin-Shepard

It is extremely cumbersome to have to worry about whether there are other concurrent accesses to the repository when running e.g. git gc. For servers, you may never be able to guarantee that nothing else is accessing the repository concurrently. Here is a possible solution:

Each git process creates a log file of the references that it has created. The log file should be named in some way with e.g. the process id and start time of the process, and simply consist of a list of 20-byte sha1 hashes to be considered additional in-use references for the purpose of garbage collection.

Quoted 6 lines · Shawn O. Pearce

Quoted 5 lines · Jeremy Maitin-Shepard

It is extremely cumbersome to have to worry about whether there are other concurrent accesses to the repository when running e.g. git gc. For servers, you may never be able to guarantee that nothing else is accessing the repository concurrently. Here is a possible solution:

Quoted 5 lines

Quoted 5 lines

Each git process creates a log file of the references that it has created. The log file should be named in some way with e.g. the process id and start time of the process, and simply consist of a list of 20-byte sha1 hashes to be considered additional in-use references for the purpose of garbage collection.

How would that solve the issue that you should not prune/gc the repository "clone --shared" aka "alternates" borrows from?

By the way, I do not think your "git-commit stopped for two weeks due to a long editing session of the commit message" should result in any object lossage, as the new objects are all reachable from the index, and the new tree nor the new commit hasn't been built while you are typing (rather, not typing) the log message.

Hmm, a partial commit that uses a temporary index file may lose, come to think of it. Perhaps we should teach reachable.c about the temporary index file as well. I dunno.

When you create a new working directory, you would also create in the original repository a symlink named
e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that points to the .git directory of the newly created working directory.

Quoted 4 lines · Jeremy Maitin-Shepard

When you create a new working directory, you would also create in the original repository a symlink named
e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that points to the .git directory of the newly created working directory.

That assumes you _can_ write to the original repository. That may or may not be the case, depending on your setup.

Quoted 9 lines · Jeff King

Quoted 4 lines · Jeremy Maitin-Shepard

When you create a new working directory, you would also create in the original repository a symlink named
e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that points to the .git directory of the newly created working directory.

That assumes you _can_ write to the original repository. That may or may not be the case, depending on your setup.

Well, I suppose in that case it could print a warning or maybe fail without some "force" option. If you can't write to the repository, then I think it is safe to say that it will never know or care about you, so you will fundamentally have a fragile setup. I'd say that except in very special circumstances, you are better off just not sharing it at all.

Hi,

Quoted 9 lines · Jeremy Maitin-Shepard

Quoted 6 lines · Jeff King

Quoted 4 lines · Jeremy Maitin-Shepard

When you create a new working directory, you would also create in the original repository a symlink named
e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that points to the .git directory of the newly created working directory.

Quoted 2 lines

Quoted 2 lines

That assumes you _can_ write to the original repository. That may or may not be the case, depending on your setup.

FWIW this argument can be found in the mailing list. It does not have to be told over and over again, right?

Quoted 6 lines

Well, I suppose in that case it could print a warning or maybe fail without some "force" option. If you can't write to the repository, then I think it is safe to say that it will never know or care about you, so you will fundamentally have a fragile setup. I'd say that except in very special circumstances, you are better off just not sharing it at all.

Counterexample kernel.org. Counterexample repo.or.cz.

Quoted 13 lines · Johannes Schindelin

Quoted 11 lines · Jeremy Maitin-Shepard

Quoted 8 lines · Jeff King

Quoted 5 lines · Jeremy Maitin-Shepard

When you create a new working directory, you would also create in the original repository a symlink named e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that points to the .git directory of the newly created working directory.

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

That assumes you _can_ write to the original repository. That may or may not be the case, depending on your setup.

FWIW this argument can be found in the mailing list. It does not have to be told over and over again, right?

Maybe you can point me at the relevant thread. Fundamentally, though, I'd say objects/info/alternates _cannot_ work reliably without the source repository knowing about the objects that the sharing repositories need. Otherwise, there is no way for it to know not to prune them. The only way for it to have that information in general is to write it in the repository. In a site-specific setting, it may indeed be possible to rely on some site-specific database, but that is not particularly relevant.

Currently repository sharing seems to be used in many cases in quite unsafe ways. It may seem unfortunate that doing things the "safe way" is much more of a hassle and doesn't work in certain environments, but I'd say that is just the way things have to be.

Perhaps you can point me to an existing thread that addresses this idea, though.

Quoted 8 lines

Quoted 6 lines

Well, I suppose in that case it could print a warning or maybe fail without some "force" option. If you can't write to the repository, then I think it is safe to say that it will never know or care about you, so you will fundamentally have a fragile setup. I'd say that except in very special circumstances, you are better off just not sharing it at all.

Counterexample kernel.org. Counterexample repo.or.cz.

repo.or.cz is not a counterexample. It is completely "managed", and could quite easily implement the approach I described.

There is the issue that these setuid helper scripts would mean at the very least that if user A can "fork" user B's repository, then to some extent user B can make user A use large amounts of disk space (i.e. exceed his quota or something) by just referencing a bunch of temporary objects that user A happens to have in his repository, and it would take careful examination of the git repository to actually figure out that it is user B's fault. I don't think this would be a significant problem in practice, though.

Well, I think that the setuid helper script would open a whole bunch of other issues.

I think that the shared repository problem is rather a semantic one, i.e. it is only solvable between the owners of the repository by good-ole talking, not something that can be solved by the tool (Git).

Quoted 5 lines · Jeremy Maitin-Shepard

It is extremely cumbersome to have to worry about whether there are other concurrent accesses to the repository when running e.g. git gc. For servers, you may never be able to guarantee that nothing else is accessing the repository concurrently. Here is a possible solution:

Quoted 5 lines

Each git process creates a log file of the references that it has created. The log file should be named in some way with e.g. the process id and start time of the process, and simply consist of a list of 20-byte sha1 hashes to be considered additional in-use references for the purpose of garbage collection.

I believe we partially considered that in the past and discarded it as far too complex implementation-wise for the benefit it gives us.

The current approach of leaving unreachable loose objects around for 2 weeks is good enough. Any Git process that has been running for 2 weeks while still not linking everything it needs into the reachable refs of that repository is already braindamaged and shouldn't be running anymore.

If we are dealing with a pack file, those are protected by .keep "lock files" between the time they are created on disk and the time that the git-fetch or git-receive-pack process has finished updating the refs to anchor the pack's contents as reachable. Every once in a while a stale .keep file gets left behind when a process gets killed by the OS, and its damn annoying to clean up.

I'd hate to clean up logs from every little git-add or git-commit that aborted in the middle uncleanly.

Also, should --keep-unreachable be deprecated / removed?

I still like Geert's suggestion of unpacking them to a _different_ place. That helps to avoid spurious "gc --auto" invocations caused by too many prunable objects. Though it certainly doesn't solve it, and maybe that just needs to be fixed separately.

Possibly the "gc --auto" test should be:

- count objects; if too few, exit
- count unreachable loose objects; if too few, exit

- run gc

That means having a lot of unreachable objects will still incur some extra processing, but not as much as a full repack. And it won't bug the user with a "you need to repack" message.

I'm now starting to wonder if there is a reason for keeping unreachable objects that used to be packed. Putting --keep-unreachable aside for now, the only way an unreachable object could have entered a pack is if it used to be reachable before through the commit history or reflog. So if they're not reachable anymore, that's most probably because their reflog expired. So what's the point for keeping them even longer? What's the reasoning that led to the creation of --keep-unreachable in the first place?

git-repack.sh do · line 33

Quoted 2 lines · On Fri, May 09, 2008 at 11:01:55PM -0500, [email protected] wrote:

git-repack.sh +1 -1

-             keep_unreachable=--keep-unreachable ;;
+             keep_unreachable=t ;;

Can we call this something else (like unpack_unreachable) since it now has nothing to do with the --keep-unreachable flag?

Also, should --keep-unreachable be deprecated / removed?

git-repack.sh then · line 139

Quoted 10 lines

git-repack.sh +10 -0

+                     *)
+                             rm -f "$e.idx" "$e.keep"
+                             if test -n "$keep_unreachable" &&
+                                test -f "$e.pack"
+                             then
+                                     git unpack-objects < "$e.pack" || {
+                                             echo >&2 "Failed unpacking unreachable objects from redundant pack file $e.pack"
+                                             exit 1
+                                     }
+                             fi

I still like Geert's suggestion of unpacking them to a _different_ place. That helps to avoid spurious "gc --auto" invocations caused by too many prunable objects. Though it certainly doesn't solve it, and maybe that just needs to be fixed separately.

Possibly the "gc --auto" test should be:

- count objects; if too few, exit
- count unreachable loose objects; if too few, exit
- run gc

That means having a lot of unreachable objects will still incur some extra processing, but not as much as a full repack. And it won't bug the user with a "you need to repack" message.

I've got a thought. How about limiting how often auto repack repacks by looking at the timestamp of the most recent pack? Wouldn't the packs already be prepared in most cases i.e. prepare_packed_git()

Quoted 3 lines · Brandon Casey

Is this invocation of pack-objects that you commented on necessary though? This is the section that is replacing an existing pack file with a newly created pack file of the same name...

Yuck, I failed to see it in the context. You are right. This won't do anything I suspect.

Perhaps we would want a new option --eject that causes pack-object write out unreachable packed objects in the loose format? This would require a minor surgery to write_sha1_file() so that it won't pay attention to the return value of has_sha1_file(sha1), perhaps like this.

This is a lunch-time hack and needs more serious work, such as fixing horrible "write_sha1_file_1" to something more sensible.

Also it should add --eject as an independent and incompatible option instead of dropping --keep-unpacked support.

---

 builtin-pack-objects.c |   56 ++++++++++++-----------------------------------
 sha1_file.c            |    9 ++++++-
 2 files changed, 22 insertions(+), 43 deletions(-)

builtin-pack-objects.c +15 -41

index 777f272..8240a4b 100644
@@ -1836,38 +1836,25 @@ struct in_pack {
       struct in_pack_object *array;
 };
 
-static void mark_in_pack_object(struct object *object, struct packed_git *p, struct in_pack *in_pack)
+static void eject_object(struct object *obj)
 {
-       in_pack->array[in_pack->nr].offset = find_pack_entry_one(object->sha1, p);
-       in_pack->array[in_pack->nr].object = object;
-       in_pack->nr++;
-}
-
-/*
- * Compare the objects in the offset order, in order to emulate the
- * "git-rev-list --objects" output that produced the pack originally.
- */
-static int ofscmp(const void *a_, const void *b_)
-{
-       struct in_pack_object *a = (struct in_pack_object *)a_;
-       struct in_pack_object *b = (struct in_pack_object *)b_;
+       enum object_type type;
+       unsigned long size;
+       void *data;
+       unsigned char sha1[20];
 
-       if (a->offset < b->offset)
-               return -1;
-       else if (a->offset > b->offset)
-               return 1;
-       else
-               return hashcmp(a->object->sha1, b->object->sha1);
+       data = read_sha1_file(obj->sha1, &type, &size);
+       assert(data && type == obj->type);
+       if (write_sha1_file_1(data, size, typename(type), sha1, 1))
+               die("cannot eject packed object %s", sha1_to_hex(obj->sha1));
+       assert(!memcmp(sha1, obj->sha1));
 }
 
-static void add_objects_in_unpacked_packs(struct rev_info *revs)
+static void eject_objects_in_unpacked_packs(struct rev_info *revs)
 {
       struct packed_git *p;
-       struct in_pack in_pack;
       uint32_t i;
 
-       memset(&in_pack, 0, sizeof(in_pack));
-
       for (p = packed_git; p; p = p->next) {
               const unsigned char *sha1;
               struct object *o;

@@ -1881,28 +1868,15 @@ static void add_objects_in_unpacked_packs(struct rev_info *revs)
               if (open_pack_index(p))
                       die("cannot open pack index");
 
-               ALLOC_GROW(in_pack.array,
-                          in_pack.nr + p->num_objects,
-                          in_pack.alloc);
-
               for (i = 0; i < p->num_objects; i++) {
                       sha1 = nth_packed_object_sha1(p, i);
                       o = lookup_unknown_object(sha1);
-                       if (!(o->flags & OBJECT_ADDED))
-                               mark_in_pack_object(o, p, &in_pack);
+                       if (o->flags & OBJECT_ADDED)
+                               continue;
                       o->flags |= OBJECT_ADDED;
+                       eject_object(o);
               }
       }
-
-       if (in_pack.nr) {
-               qsort(in_pack.array, in_pack.nr, sizeof(in_pack.array[0]),
-                     ofscmp);
-               for (i = 0; i < in_pack.nr; i++) {
-                       struct object *o = in_pack.array[i].object;
-                       add_object_entry(o->sha1, o->type, "", 0);
-               }
-       }
-       free(in_pack.array);
 }
 
 static void get_object_list(int ac, const char **av)

@@ -1938,7 +1912,7 @@ static void get_object_list(int ac, const char **av)
       traverse_commit_list(&revs, show_commit, show_object);
 
       if (keep_unreachable)
-               add_objects_in_unpacked_packs(&revs);
+               eject_objects_in_unpacked_packs(&revs);
 }
 
 static int adjust_perm(const char *path, mode_t mode)

sha1_file.c +7 -2

index 3516777..ce3a661 100644
@@ -2102,7 +2102,7 @@ int hash_sha1_file(const void *buf, unsigned long len, const char *type,
       return 0;
 }
 
-int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
+int write_sha1_file_1(void *buf, unsigned long len, const char *type, unsigned char *returnsha1, int refresh)
 {
       int size, ret;
       unsigned char *compressed;

@@ -2120,7 +2120,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
       filename = sha1_file_name(sha1);
       if (returnsha1)
               hashcpy(returnsha1, sha1);
-       if (has_sha1_file(sha1))
+       if (!refresh && has_sha1_file(sha1))
               return 0;
       fd = open(filename, O_RDONLY);
       if (fd >= 0) {

@@ -2185,6 +2185,11 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
       return move_temp_to_file(tmpfile, filename);
 }
 
+int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
+{
+       return write_sha1_file_1(buf, len, type, returnsha1, 0);
+}
+
 /*
 * We need to unpack and recompress the object for writing
 * it out to a different file.

On Fri, May 9, 2008 at 4:23 PM, Junio C Hamano <[email protected]> wrote:
The remainder of your email is below since the list has never seen it.

Quoted 2 lines

Perhaps we would want a new option --eject that causes pack-object write out unreachable packed objects in the loose format?

According to that commit message, prune is now a no-op. However, it looks like it is still used for trigger a "repack -a" rather than "repack -A".