Re: Subproject status

On Mon, 26 Mar 2007, Martin Waitz wrote:

You can try to play with my prototype:
git.admingilde.org/tali/git.git, branch module2
(to get an example of how to use it, look at the test script in
t/t7500-submodule.sh).

I tried that yesterday, but I fail reading comprehension; I lost the 
"module2" bit by the time I actually fetched. I'll look into this.

The core operations should work, but not all the user interface is
adapted to support submodules.  E.g. git-status will not show if a
submodule has dirty changes, it will only show submodule changes which
are already commited to the submodule but not yet to the supermodule.
But at least simple merges do work with submodules.

I abondoned this branch (no further work, only occasionally pulling in
updates from upstream git.git) as it has scalability problems with
large projects.

That's what I remember. But it's only an issue with super-scale projects 
(i.e., where your subprojects are full-sized projects in their own right, 
and you've got a hundred of them), right? I'm working on the other end 
(factoring out the common bit from a bunch of similar small projects), so 
I should be fine with respect to scalability of the implementation.

Would you guess that a patch series to complete the module2 user interface 
adaptation would also apply to module3 and therefore be useful in the 
future?

The objects created by the module2 and module3 branches are the same,
module3 only moves those belonging to the submodule to another location.
So If you start using module2 branch now you should be able to upgrade
later.  But to be extra sure, we should have some discussion about the
object format here.  (There is nothing new here, really: Just one more
tree entry file mode which says that this is not a file or directory
entry, but a submodule, represented by one commit.)

So, I had the nutty idea that it would be convenient if I could make 
different files in a single directory come from different projects. But I 
can't think of a sane user interface, so I think that this isn't 
practical from that direction, so it's probably not worth worrying about 
from the data structure end, either. (Answer for the usecase: 
"ln -s make/Makefile Makefile; git add Makefile", and mock systems that 
don't handle symlinks).

But, just to be clear, the semantics of having a commit abcd at a path foo 
are, with respect to the tree this represents, that abcd:* appears at 
foo/*. Right?

Are there any standards we should discuss with respect to refs related to 
subprojects?

I've updated the wiki page with this information.

	-Daniel
*This .sig left intentionally blank*