Jakub Narebski <jnareb@xxxxxxxxx> writes:
> Do I understand correctly that toplevel (master project) commits have tree
> which points to combined tree, and "bind" links which points to the
> subprojects commits whose trees make up the overall tree, or does the
> master tree points to tree containing only toplevel files (overall Makefile
> for example, INSTALL or README for the whole project including
> subprojects,...)?
The plan for "bind commit" was to have the toplevel commit to
contain:
tree -- this covers the whole tree including subprojects
parent -- list of parents in the toplevel project
bind -- commit object name of subproject, plus which
directory to graft its tree onto.
And a subproject commit, unless it contains subsubproject, would
look like just an ordinary commit. Its tree would match the
entry in the tree the toplevel commit at the path in "bind" line
of the top-level commit.
Some reading material, from newer to older:
* http://www.kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=Subpro.txt
This talks about the overall "vision" on how the user-level
interaction might look like, with a sketch on how the core-level
would help Porcelain to implement that interaction. Most of the
core-level support described there is in the "bind commit"
changes, except "update-index --bind/-unbind" to record the
information on bound subprojects in the index file.
* http://thread.gmane.org/gmane.comp.version-control.git/15072
This was the thread that led to the above proposal.
* http://thread.gmane.org/gmane.comp.version-control.git/14486
This is older. It touches an alternative "gitlink" approach,
which I meant to prototype but never got around to.
Surprisingly, these two threads are mostly noise-free and
literally every message is worth reading.
Some old but working core-side code is available at jc/bind
branch of public git.git repository.
> BTW. I have lately stumbled upon (somewhat Vault and Subversion biased)
> http://software.ericsink.com/Beyond_CheckOut_and_CheckIn.html
> Read about Share and Pin -- it's about subprojects (when you edit out the
> flawed "branch as folder" approach of author).
Not really. You can easily do that by checking out another
project in a separate subdirectory.
My private working area for git.git is structured like this:
/home/junio/git.junio/.git
Makefile
COPYING
Documentation/
...
Meta/.git
Meta/TODO
Meta/Make
Meta/TO
Meta/WI
...
Notice two .git directories? That's right.
The top-level .git repository has the familiar branches like
"maint", "master", "next", "pu", in addition to various topic
branches.
Meta/.git is a separate repository that is a clone of "todo"
branch of git.git repository. The top-level .git repository
does not even have "todo" branch. I just happen to push into
the same public repository git.git at kernel.org from these two
separate repositories.
The Meta/ repository is "pinned" to a specific version, without
having any funky "Pin feature", no thank you, because I have
full control of when I update what is checked out in the Meta/
directory.
What you _might_ want is a reverse of Pinning. Sometimes, you
would want to make sure subproject part is at least this version
or later to build other parts of the whole.
But for my particular "Meta/" directory, I do not need such a
linkage. The major reason I do not keep TODO in the main
project is because it is supposed to be a task list for me
across "maint", "master" and "next". I do not want it to
fluctuate whenever I work on different branches.
-jc
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html