Re: Considering teaching plumbing to users harmful

[Jakub Narebski <jnareb@gmail.com>]

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).
-- 
Jakub Narebski
Poland