Shawn O. Pearce wrote:
quoted text
> 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))

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

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

-
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