Re: Subproject status

[Daniel Barkalow <barkalow@iabervon.org>]

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*