Brandon Casey <casey@nrlssc.navy.mil> wrote:
quoted text
> ok. I just want to make sure this is not really about prune'ing.
> 
> In the following, source and --shared repos are identical except...
> 1) Source repo contains loose objects which are new commits.
>    --shared repo does git-pull.
>    we fast-forward, copying very little.
>    success.

Copying nothing actually.  All of the objects required are in the
source repository, so --shared needs nothing additional.

quoted text
> 2) Source repo contains loose objects which are new commits.
>    Source repo does git-gc, which repacks but doesn't prune.
>    --shared repo does git-pull.
>    success?

Yes, same as above.  Except: If --shared has a branch that points
at a commit that used to be in source (hence its data isn't in
--shared) and that data used to be packed, but source no longer
has a reference to it.  When you repack source we won't include
that commit in the new pack, but we will delete the old pack.
That means the commit goes away.

quoted text
> 3) Source repo deletes a branch that --shared repo also has.
>    This deletion creates dangling unreferenced objects.

Yes... see above about the repack problem.

quoted text
> ** --shared repo still ok here, right?
>    Source repo does git-gc, which repacks but doesn't prune.

Broken.  The repack didn't include the dangling objects.

quoted text
> ** Is --shared screwed at this point? (This is what I understand
>      you to say above) Or do the dangling objects still exist,
>      so --shared is still ok?

--shared is fubar, on the deleted branch.

quoted text
>    git gc --prune
>    --shared is fubar, at least on the deleted branch.

also fubar, on the deleted branch.

quoted text
> The docs (git-repack.txt) seem to suggest that git-repack (without -d) 
> does not delete any objects. And if -d is used, then at most objects 
> already referenced in other packs will be deleted. This makes me think 
> that repack is safe on the source repository.

You are correct that leaving off the '-d' won't delete objects.
But a pack is created by listing the objects we need, and if we don't
need the object in source, we don't include it into the new pack.

-a -d implies delete all packs that existed when we started the
repack.  So if an object was in the old packfile, and we didn't
copy it to the new packfile, it gets deleted.  ;-)

Packfiles are immutable.  We cannot delete something from it without
deleting the entire packfile.
 
quoted text
> If the above is wrong, then I'm missing a clue about git-rebase. And 
> don't feel like you have to explain it to me. Do feel free to give a 
> short *NO!! REPACK IS DANGEROUS ON SHARED REPOS YOU IDIOT!!* or other 
> such beating. But if you see what I'm misunderstanding please let me know.

;-)

NO!! REPACK IS DANGEROUS ON SHARED REPOS YOU IDIOT!!

Exactly because of what I'm saying above, and what you mention about
source deleting a branch and repacking or pruning, and --shared
then being corrupt because its now missing at least one object it
wants to have.
 
quoted text
> If the above is right, then it seems like the source repo developer 
> should be able to go about his developing, and git-gc'ing without
> regard for other developers who may be --share'ing. And only when the
> source developer wants to do a prune of dangling objects must something 
> special be done. git-prune.txt suggests:
> 
>     git prune $(cd ../another && $(git-rev-parse --all))

Right; but the thing that is shocking to some people (me in my
early days with Git) is that a repack is *also* doing a prune if
you add -d.  Its not quite the same type of prune as it prunes only
previously packed objects, but its still a prune.
 
quoted text
> >In my day-job repositories I have about 150 MiB of blobs that
> >are very common across a number of Git repositories.  I've made a
> >single repo that has all of those packed, and then setup that as an
> >alternate for everything else.  It saves a huge chunk of disk for us.
> >But that common-blob.git thing that I created never gets changed,
> >and never gets repacked.  Its sort of a "historical archive" for us.
> >Works very nicely.  Alternates have their uses...
> 
> Ahh, now that's interesting.
> 
> Could I create something like that by doing something like this:
> 
> (in a cloned repository with only a master branch)
> git reset --hard HEAD^     # I know, HEAD is still in the history
> git gc --prune             # log so it doesn't get pruned, but
>                            # it's just an example
> 
> (now back in my devel repo)
> <add archive repo to alternates>
> git prune-packed

Actually you want `git gc` in your --shared repo now.  That way it
minimizes the current packfiles.  prune-packed only applies to loose
objects; not already packed stuff.  Since you added a repo with a
large packfile to your alternates list you probably want to shrink
your own packfile down as much as possible.  That works because
`git gc` is actually running `git repack -a -d -l`.  The -l means
"only things that are local to this --shared repository.
 
quoted text
> Now most everything is likely referenced in the archive repo except the 
> last commit. Well, maybe even the HEAD commit due to the history log.

Right.
 
quoted text
> Depending on how you reply above, a periodic pull into the archive repo 
> (and a repack?), then a 'git prune-packed' from the sharers could allow 
> good sharing? <waiting for a "NO, YOU IDIOT!"> If not, then I guess the 
> archive creation steps could be repeated periodically.

Yes, exactly.  The trick here is that once something enters the
shared repo IT MUST STAY THERE.  You cannot allow a branch to be
deleted from the shared repo, unless it is fully merged into another
branch (or tag) that is staying.  You also cannot rewind a branch
(e.g. push with --force).

But I do exactly what you are suggesting.  I pull every so often
into a the shared common repo and repack it.  And then everyone
else can repack and their repack deletes things that are in the
shared common repo.

Just make sure you have a good backup of the shared common repo.  :)

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html