Re: Fetching everything in another bare repo

From: Paul Smith <paul@mad-scientist.net>
Date: Mar 9, 2023, 18:15 UTC
Message-ID: <42ea54b4b4d74d6760faca8325a657ee71f342d7.camel@mad-scientist.net>
In-Reply-To: <ZAn80gnIFLOF4Gco@coredump.intra.peff.net>

On Thu, 2023-03-09 at 10:35 -0500, Jeff King wrote:

Show 8 quoted lines

> > Basically, these bare clones have "gc.pruneExpire=never" set, and
> > have never had any GC operations run so all commits are still
> > present (when you say "unreachable" I assume you mean, not
> > reachable through any reference).
> 
> Right, that's what I mean by unreachable. And no, you didn't use any
> terminology wrong. I was just not sure if you realized that running
> "fetch" would not get the unreachable objects. :)

I definitely did not realize that, so good looking out :)

Of course in retrospect it makes perfect sense: why would you fetch unreachable objects (normally)?

Show 5 quoted lines

> > One question: is the objects/info/packs file anything to be
> > concerned about or will git repack (or something) take care of
> > handling it?
> 
> You can ignore it.

OK thx.

> Yeah, if you have a separate database of branch tips, etc, then the
> refs aren't necessary. As long as you are careful not to run "gc" or
> repack without "-k".

It's actually a code review facility so it doesn't even care about branches, it's basically just storing before/after SHAs of changes to be reviewed. But the historical code reviews can sometimes be gold, even if they're some years old, so I'd prefer to keep them available.

> You may want to try the "preciousObjects" repository extension, which
> was designed to prevent accidents for a case like this.

Oh interesting, I'll take a look.

Cheers!