Re: Considering teaching plumbing to users harmful

> On Thu, 17 July 2008, Kevin Ballard wrote:
>> On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:
>>
>>> Git submodules are roughly equivalent to svn:externals with peg
>>> revisions; I mean here that they refer not to some branch in some
>>> external repository, but to specific revision.  This is the only  
>>> sane
>>> design, as it assures that when checking out some historical  
>>> revision,
>>> the state that is checked out will be the same for everybody.
>>>
>>> Please take into account however that submodules are quite new
>>> feature, and while underlying engine is solid, interface (UI) needs
>>> some polishing (and use cases).
>>
>> There is one facet of submodules that annoys me, because it prevents
>> me from using them as a replacement for svn:externals. Namely, the
>> submodule refers to a specific repository, but not a path within that
>> repository. I work with svn repos that use svn:externals to peg
>> revisions (as is appropriate) but they all refer to various paths
>> within the other repositories, and the only way I can deal with that
>> is to throw symlinks everywhere.
>
> I don't quite understand.  At the lowest, "gitlink" level submodule
> entry is just having _commit_ object in place of directory.  And of
> course this commit object refers to top tree (top directory) in
> a subproject.
>
> If you have subproject B with the following file structure
>
>  B/foo
>  B/bar/baz
>
> and you have (super)project A, which contains B as subproject at path
> sub-b, and has some files itself, the directory sytucture would look
> like this:
>
>  A/quux
>  A/sub-b/foo
>  A/sub-b/bar/baz
>
>
> What you want, I guess, is some a bit weird for me mixture of  
> submodule
> and partial (subtree) checkout... and the latter is not implemented  
> yet
> (I say "yet" because there was some preliminary implementation of
> subtree checkout on git mailing list).