Re: [PATCH 6/6] Teach core object handling functions about gitlinks

On 4/12/07, Martin Waitz [off-list ref] wrote:

On Thu, Apr 12, 2007 at 02:42:43AM +0200, Torgil Svensson wrote:

quoted

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