Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links

From: Junio C Hamano <junkio@cox.net>
Date: Apr 26, 2006, 07:50 UTC
Message-ID: <7virowrd1y.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e2n72h$aqe$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> writes:

Show 6 quoted lines

> 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