Re: [RFC][PATCH] Cogito support for simple subprojects

From: Junio C Hamano <junkio@cox.net>
Date: Jan 15, 2006, 19:15 UTC
Message-ID: <7vk6d1480z.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060115150721.GE28365@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 5 quoted lines

> ... I currently don't
> think a recursive cg-merge is a particularily good idea, for one.
> I think the good default is to make all read-only commands by default
> recursive and all modifying commands by default non-recursive. (And
> it might be useful to be able to mark some subprojects read-only.)

All sounds sane and simple.  Good job!

Especially because this does not even try to let the project express its version dependencies on its subprojects, I like it for its simplicity (which makes it very easy to explain, to my mind that is the biggest plus). However, I fear that others might complain to say that the contained things do not deserve to be called "subprojects" if there is no version linkage [*1*].

I think something like this is greatly helpful for people (like me) as "an end user who builds from source out of SCM not from tarballs."

If you go this route, one minor concern is what the format of the $GIT_DIR/subproject should be (and if they do not deserve to be called "subproject" then what the name of the file be), because this may likely be a "nice if they were compatible" item across Porcelains. The list of names separated with LF has two very big pluses:

 - it is certainly the easiest to parse.

 - it can readily be used as --exclude-from file, as long as you
   do not care about another directory with a same name
   somewhere other than the subproject itself.

Even if the limitation to the latter becomes a real issue, a separate exclude-from file could easily be generated on the fly (prefix them with '/' to force "not anywhere in the subtree but only here" matching, perhaps with escaping shell glob pattern while you are at it), which does not sound so bad.

[Footnote]

*1* I do not personally care about version linkage; this is me being lazy to avoid core side support ;-). Yesterday I was mucking with rev-list code to see how gitlink and/or bind commit would affect what it needs to do (especially wrt its --objects flag), and I did not like the potential code impact I saw there.