Shawn O. Pearce wrote:
Brandon Casey <casey@xxxxxxxxxxxxxxx> 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))
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
