Re: Subproject status

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 27, 2007, 00:04 UTC
Message-ID: <Pine.LNX.4.64.0703261920070.6485@iabervon.org>
In-Reply-To: <20070326093906.GF22773@admingilde.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.

Show 9 quoted lines

> 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?

Show 7 quoted lines

> 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*