On Fri, Dec 01, 2006 at 06:33:12PM +0100, Stephan Feder wrote:
quoted text
> We are in agreement about two fundamental parts of the implementation=20
> and their meaning:
>=20
> 1. A submodule is stored as a commit id in a tree object.
>=20
> 2. Every object that is reachable from the submodule's commit are=20
> reachable from the supermodule's repository.

Correct.

quoted text
> >>For example, git has the subproject xdiff. If git had been able to work=
=20
quoted text
> >>with subprojects as I envision, and if xdiff had been published as a gi=
t=20
quoted text
> >>repository (not necessarily subproject enabled), it could have been=20
> >>pulled in git's subdirectory xdiff as a subproject.
> >
> >This could have been done if submodule support would have been available
> >at the time xdiff was introduced, yes.
> >
> >>There would not have been a separate branch or even repository for
> >>xdiff in the git repository.
> >
> >What separate branch or repository are you talking about?
>=20
> That's it: There is no need for a separate branch or repository. If you=
=20
quoted text
> have the subproject's commit in the superproject's object database (and=
=20
quoted text
> we really have that, see 1. and 2. above), why do you _have to_ store it=
=20
quoted text
> elsewhere?

Let's see if I understand you correctly:

You don't want to create an additional .git directory for the submodule
and just handle everything with one toplevel .git repository for the
whole project.
Without the .git directory, you of course do not have refs/heads inside
the submodule.

So this is a different user-interface approach to submodules when
compared to my approach.  But the basis is the same and both could
inter-operate.

Now your submodule is no longer seen as an independent git repository
and I think this would cause problems when you want to push/pull between
the submodule and its upstream repository.
No technical problems, but UI-problems because now your submodule is
handled completly different to a "normal" repository.


quoted text
> >Yes, but if it would have been integrated as a submodule it obviously
> >would have been committed to the xdiff submodule inside the git
> >repository.
>=20
> No. The xdiff submodule would only exist as part of the git repository.=
=20

But you could still call the "xdiff" part of the git repository a
submodule.  And then changes to the xdiff directory result in a new
submodule commit, even when there is no direct reference to it.
So you'd still "commit to the xdiff submodule".

quoted text
> You could, f.e., access the xdiff commit in git HEAD as HEAD:xdiff//=20
> (again my proposed syntax). HEAD:xdiff//~2:xemit.c would give you the=20
> grandparent of xemit.c in the xdiff submodule.

git-cat-file commit HEAD:xdiff already works out of the box (even
cat-file tree to get the submodule tree).  But up to now revision
parsing follows the file name only once.

What about just separating things with "/"?

commit HEAD
tree   HEAD/
blob   HEAD/Makefile
commit HEAD/xdiff
tree   HEAD/xdiff/
blob   HEAD/xdiff~2/xemit.c

this may add some confusion when used with hierarchical branches, but
it's still unique:

	refs/heads/master/xdiff/xemit.c

Just use as many path components until a matching reference is found,
then start peeling.
Or just use / between super and submodule:

	refs/heads/master:xdiff/xemit.c

I think this is easier to read then

	refs/heads/master:xdiff//:xemit.c


quoted text
> If you mean the submodule repository created by init-module I=20
> understand. But why create this "helper repository at all"?

Because it helps "normal" git operations ;-)

--=20
Martin Waitz