Shawn O. Pearce wrote:
quoted text
> Brandon Casey <casey@nrlssc.navy.mil> wrote:

[snip]

quoted text
>> 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.

quoted text
> 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]

quoted text
>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html