On 4/12/07, Martin Waitz <tali@xxxxxxxxxxxxxx> wrote:
On Thu, Apr 12, 2007 at 02:42:43AM +0200, Torgil Svensson wrote: > I guess this file could also cover the case where the superproject is > only interested in a small subset of the subproject. For example if I > only uses some header-files in a library and want > "/lib1/src/interface" in the subproject end up as "/includes/lib1" in > the superproject. Could single files be handled in a similar way? Conceptionally this information would have to be part of the supermodule tree (after all it changes how your tree is set up).
I agree. This could be included in the module config file which in turn is version-controlled.
I think it makes more sense to make users think about which part of their tree can be reused and make them choose submodule boundaries wisely so that the above partial-checkout is not needed.
Sometimes you can't control upstream projects the way you want it. Also, splitting up projects for the potential need of future superprojects has several obvious disadvantages (multiple changelogs, versions etc). I don't see the subfolder checkout thing as a problem since the core plumbing in Linus's implementation doesn't care what's beneath the commit link. The subfolder checkout can "easily" be done in a porcelain. It's more problematic if you want to cherry-pick individual files in a subproject. Here, I think the tight connection between links and directories to be too restrictive. Why does a subproject commit-link have to be represented as a folder? //Torgil - To unsubscribe from this list: 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