Re: clarify git clone --local --shared --reference

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Jun 6, 2007, 18:50 UTC
Message-ID: <466701E0.4000108@nrlssc.navy.mil>
In-Reply-To: <20070606051111.GF9513@spearce.org>

Shawn O. Pearce wrote:

Show 25 quoted lines

> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Shawn O. Pearce wrote:
>>>  b) Don't repack the source repository without accounting for the
>>>  refs and reflogs of all --shared repositories that came from it.
>>>  Otherwise you may delete objects that the source repository no
>>>  longer needs, but that one or more of the --shared repositories
>>>  still needs.
>> How should this be accomplished? Does this mean never run 
>> git-gc/git-repack on the source repository? Or is there a way to
>> cause the sharing repositories to copy over objects no longer
>> required by the source repository?
> 
> Well, you can repack, but only if if you account for everything.
> The easiest way to do this is push every branch from the --shared
> repos to the source repository, repack the source repository, then
> you can run `git prune-packed` in the --shared repos to remove
> loose objects that the source repository now has.
> 
> You can account for the refs by hand when you run pack-objects
> by hand, but its horribly difficult compared to the push and then
> repack I just described.  I think that long-lived --shared isn't that
> common of a workflow; most people use --shared for shortterm things.
> For example contrib/continuous uses --shared when it clones the
> repository to create a temporary build area.
>

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.
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?
3) Source repo deletes a branch that --shared repo also has.
    This deletion creates dangling unreferenced objects.
** --shared repo still ok here, right?
    Source repo does git-gc, which repacks but doesn't prune.
** 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?
    git gc --prune
    --shared is fubar, at least on the deleted branch.

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.

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.

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))

Show 7 quoted lines

> 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

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.

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.

-brandon