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.
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*
Daniel Barkalow
