Re: RFC: Subprojects

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

In "pu", I have some of the necessary basic pieces for "bind" approach, barely enough so that anybody interested could start prototyping using them as building blocks. It still has very rough edges; the missing includes rev-list and fsck-objects, so you cannot do a send-pack or fetch-pack yet.

Yesterday I was working on "gitlink" approach to have similar core-side support for prototyping. I haven't finished it into a buildable state yet (it is not in "pu"), and I am pessimistic if I ever will X-<.

I think the updated "bind" thing makes the two approaches semantically equivalent (i.e. it does not allow an arbitrary overlayed setup anymore). We simply do not allow the conflicting "bind". So neither is the _only_ solution. We probably could make both to work, but the details differ.

 * With "gitlink", the index of containing project never has
   subprojects parts of the tree, which I see it as an advantage
   compared to what "bind" does.  It only has one "gitlink"
   entry per each subproject.  update-index, read-tree,
   ls-files, diff-*, etc. needs to be aware of "gitlink" object.
   Especially tricky is read-tree.  It needs to treat a
   "gitlink" object as a directory for D/F conflict detection
   purposes, but treat it similar to blobs in most other aspects
   (e.g.  results in one entry in the index).  The stat
   information update-index and diff-files uses for quick
   up-to-date check needs to be taught not to worry about the
   stat information of the subdirectory a "gitlink" object
   points at (e.g. if you do a whole-tree build, the timestamp
   of the directory would change, but that does not mean the
   subtree is dirty).  tree/directory traversal code needs to be
   aware of "gitlink" and stop there.  This approach involves
   quite a lot of code changes, mostly because what is in the
   current index never correspond to a directory on the
   filesystem but "gitlink" quacks like a directory.

 * With "bind", the index of containing project keeps the entire
   tree structure, including subproject part.  In fact, there is
   no other separate index for the subproject part.

   An updated write-tree in "pu" can write a tree for only the
   subproject part with "write-tree --prefix=<path>/" from such
   an index file, and read-tree can read with "read-tree
   --prefix=<path>/" to graft a subproject tree on top of the
   current index contents.  Without the --prefix, write-tree
   writes out the whole thing for a commit for the containing
   project, so if somebody cloned that superproject, getting the
   whole tree out in order to "make" is just the matter of doing
   a regular "read-tree && checkout-index".

   We could introduce "bind the rest" to make write-tree write
   out a tree that contains only the containing project part and
   not any of the subproject part (e.g. Makefile, README and
   src/ but not linux-2.6/ nor gcc-4.0/ in the earlier example).
   Essentially the contents of such a tree object would be the
   same as what "gitlink" approach would have had for the
   containing project in the index file, minus "gitlink" entries
   themselves).  This is not so surprising, because the missing
   information "gitlink" approach recorded in the tree object
   itself is expressed on "bind" lines in the commit object with
   this approach.

An advantage with the "bind" approach, from the implementation point of view, is that none of the "index vs working tree" part of the core needs to be modified (you would notice that many issues I had with trying "gitlink" I listed above are "index vs working tree" issues). "tree object vs index" part needed to be enhanced somewhat (e.g. the re-rooting read-tree/write-tree with the --prefix option) but it was not too painful.