Re: git submodules

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

On Sun, Aug 17, 2008 at 11:08:39PM +0000, Junio C Hamano wrote:
> I know there are cases where sharing object store is useful.  Being able
> to share is one thing.  Always having to share, without any other option,
> is another.
> 
> Using gitlink to keep the true repository data out of submodule checkout
> area so that branch switching can safely be done is orthogonal to the
> issue of how repositories of submodules and the superproject share their
> object store.  IOW, you would always use gitlink to solve the "branch
> switching may make the submodule checkout disappear" issue, while you
> could use alternates mechanism (or direct symlinking of $GIT_DIR/objects)
> across these repositories *if* you want to share their object store.

  Fair enough. Though I'm not only interested into the branch switching
issue. I'm seeing a bit farther, like in having many commands working as
if there is no submodule involved. And having the same object store for
all {sup,super}modules helps a lot. For example, there is probably quite
some plumbing to write if we have separate object stores if we expect
(and frankly I do) to have git-commit work across submodule boundaries
(doing what it should, IOW commit in the submodules, and then commit in
the supermodule).

  But maybe it's not as hard as it looks.

> > Though we would not like to have submodules suffer from reachability
> > issues after a prune in the supermodule. That means that all references
> > and reflogs of the submodules shall be accessible from the supermodule
> > so that everything that could mess with the object store by removing
> > objects cannot remove interesting objects (that should limit the code
> > paths to really seldom places actually).
> 
> I do not think this issue is limited to use of submodules.  I'd imagine
> that if you build this reachability protection into the alternates
> mechanism, you would automatically solve both "multiple checkout of the
> same project, via git-new-workdir" issue as well as "submodules that share
> its objects with the superproject" issue.
> 
> Which leads me to conclude, at least for now, that it would not be a good
> idea to make this related to gitfile in any way.  Object sharing between
> equal repositories (aka new-workdir) does not use gitfile, but it still
> needs to have the same kind of reachability protection.

  Well somehow the repository that is the alternate (or the symlink, but
the latter isn't very windows friendly, not to mention vfat) has to know
about the other repository:
  * index ;
  * references ;
  * reflogs.

  Which means that alternates users have to register into the provider,
which seems to be _usually_ brittle. I mean, for the current way of
how git-new-workdir works, if you register workdirs into the real
repository, if you just rename this workdir at some point, or move it to
some other place, you're screwed, silentely.

  If instead you force this workdir to use a gitfile, you _don't need_
to register your workdir in the "real" repository, because all the data
belongs to the "real" repository. The workdir is just a "detached"
workdir, with only the checkout stuff, no index, no references no
nothing. And if you move this workdir to a new place, it still works.
Only the central repository should not budge, which is already a
limitation of current workdirs and alternates anyways.

  Of course with submodules it's less of an issue since those arent as
loosely coupled to the supermodule as workdir are to the main
repository, and it's unlikely that a submodule will move very often ;)


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]