Shawn O. Pearce wrote:
Brandon Casey <casey@xxxxxxxxxxxxxxx> wrote:
[snip]
2) Does --shared imply shared write access? Does --local?
I'll point out that git-init has an option with the same name.
No. --shared means something entirely different in git-clone
than it does in git-init.
This did cause the thought that git-init --shared and git-clone --shared
may be pairs to be used together in some special way.
ok. Rather selfish "sharing" in my opinion :)
--reference did not cause any confusion and implied to me exactly
what it does: Use supplied repository as a reference for objects
which cannot be resolved locally.
The --shared here implies adds the source repository to the new
repository's .git/objects/info/alternates. This means that the
new clone doesn't copy the object database; instead it just accesses
the source repository when it needs data.
This exposes two risks:
a) Don't delete the source repository. If you delete the source
repository then the clone repository is "corrupt" as it won't be
able to access object data.
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?
[snip]
4) is space savings obtained only at initial clone? or is it on going?
does a future git pull from the source repository create new hard
links where possible?
Only on initial clone. Later pulls will copy. You can try using
git-relink to redo the hardlinks after the pull.
How about with --shared? Particularly with a fast-forward not much
would need to be copied over. Do later pulls into a repository with
configured objects/info/alternates take advantage of space savings
when possible?
If the answer above is "yes", then this brings up an interesting use
case. I assume that clone, fetch, etc follow the alternates of the
source repository? Otherwise a --shared repository would be unclone-able
right? And only pull-able from the source repository? So if that is the
case (that remote alternates are followed), then a group of developers
could add all of the other developers to their alternates list (if
multiple alternates are supported) and reference their objects when
possible. To the extent that it is possible, each developer would end up
only storing their commit objects. This would then create a distributed
repository.
Of course, this new distributed repository may be somewhat fragile since
the entire thing could become unusable if any portion was corrupted.
Just because you can do a thing, doesn't mean you should.
thanks for your excellent reply,
-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
