Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> On Mon, 27 Aug 2007, Petr Baudis wrote:
>
> > So now I wonder, what is the thing you miss most there?
>
> I wonder if this is repo.or.cz specific, but we recently had a problem
> where the blobs of a project went away, and the forked project still
> relied on them. Any ideas how to solve that issue?
Its not isolated to repo.or.cz.
Its what happens when you use `git clone --shared A B` and the
repository A that you borrow from removes objects that B depends
upon. That is exactly what repo.or.cz is doing, and it is exactly
what I'm doing at day-job with some large repositories.
You more or less cannot repack A without making sure it takes B's
refs into account when it generates the new packfile.
But that's actually a problem because A doesn't have B's ODB, and
some objects that are reachable through B's refs won't be available
to A for traversal or packing. Not to mention that you may not
want to stuff B's objects into A (at day-job I don't).
This is partly why Junio doesn't push to repo.or.cz/git.git but
instead pushes to alt-git.git and why he doesn't allow forking
of alt-git.git. This way his `pu` branch doesn't lose objects
and cause a fork to suffer data loss after a repack of git.git.
At day-job I have a hard rule that you cannot even push into an A,
let alone rewind a branch in it or delete a branch from it. All of
my A's that my B's fork from a strictly read-only and are managed
by me and me alone. I know what I'm doing... I think.... ;-)
So it really comes down to a rule like the following:
If `git clone --shared A B` is used then either:
- Never repack A;
- Never delete/rewind a commit in A.
If A must be repacked then:
1) Hardlink all loose objects/packs from A to all B;
2) `git --git-dir=A repack -a -d`
3) `git --git-dir=B repack -a -d -l`
4) `git --git-dir=B prune`
Ain't easy, is it? That --shared flag to git-clone is playing
with fire. If you don't want to get burnt, don't use it. Maybe
we should rename it --light-a-match-and-burn-me-please. ;-)
Forks on repo.or.cz are cool, but they can cause problems if the
root project is allowed to rewind or delete branches.
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
