Re: RFC: Subprojects

From: Junio C Hamano <junkio@cox.net>
Date: Feb 21, 2006, 07:57 UTC
Message-ID: <7v1wxx4011.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060220131659.GA8613@informatik.uni-freiburg.de>

Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:

> I'd prefer to have the objects needed to get the linux-2.6 tree in the
> object db of the containing project.  Then "url" is not needed, and you
> could directly use the commit as value for the link.

... which is actually closer to what bind commit approach gives you. The tree object in a commit of the containing project has the full tree object at path linux-2.6/. The "bind" lines in the commit object are just notes that tell you where those trees happen to came from.

> ...  Moreover the condition that the
> "containing" tree must not have an entry named linux-2.6 is handled
> implicitly with links.

I had an impression that two approaches were more or less equivalent, especially the last round of bound commit approach. It does not let anything to exist at the bound path in the containing project either ("read-tree --prefix" rejects it).

> Please correct me if I'm wrong somewhere.  It's some time ago I read the
> patches and this thread.  This mail is the result of some thoughts in my
> vacation.

I have to admit that I haven't thought about the issues involved for a long time, having no great need nor desire for subprojects myself, and especially with more generally useful stuff like performance enhancement for pack generation to occupy me. I am not sure I am much more qualified to comment than you are at this point.

The bound commit lowlevel changes have been sitting in "pu" for about a month by now, but nobody seems to be interested enough to start prototyping Porcelain around it. Neither the gitlink approach. After seeing not much interest on the list, I was hoping that I could retire both WIPs.