Re: [PATCH/RFC v2] git-submodule: multi-level module definition

On Thu, Mar 6, 2008 at 7:54 AM, Ping Yin [off-list ref] wrote:

On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano [off-list ref] wrote:
 > Ping Yin [off-list ref] writes:
 >
 >  > This patch allows multi-level module definition in .gitmodules as
 >  > Linus and Sven Verdoolaege etc. have suggested in mails
 >  > "Let .git/config specify the url for submodules"
 >  > (http://article.gmane.org/gmane.comp.version-control.git/48939).
 >  >
 >  > Following shows an example of such a .gitmodules.
 >  >
 >  > .gitmodules with with multiple level of indirection
 >  > ------------------------------------------------------
 >  > [submodule "service"]
 >  >    submodule = crawler
 >  >    submodule = search
 >  > ...
 >
 > > [submodule "util"]
 >  >    url = git://xyzzy/util.git
 >  > [submodule "imsearch"]
 >  >    path = search/imsearch
 >  >    url = git://xyzzy/imsearch.git
 >  > [submodule "imcrawler"]
 >  >    path = crawler/imcrawter
 >  >    url = git://xyzzy/imcrawter.git
 >  > ------------------------------------------------------
 >
 >  I would agree that allowing the user to use a short-hand to name a group
 >  of modules the user is interested in would be a good idea, but I think
 >  .gitmodules is a wrong place to do so.  The grouping is a user preference,
 >  isn't it?
 >
 >  The place the owner of the repository (not the project) expresses which
 >  modules are of interest, what transports she wants to use to access it,
 >  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to
 >  be used when the user populates that information.
 >
 Not always the case. In my company environment, we have many
 submodules and have a unified hierachy of modules, and we use the same
 transports ssh. So after top maintainer give the basic module hierachy
 config in .gitmodules, other people needn't and even shouldn't
 consider changing these common config. If other people have special
 needs, they can of course edit .git/config to add new hierachy or
 override existing ones in .gitmodules. However, it's better to put the
 common config in .gitmodules to pass to every one.

I am a bit confused about why we need it as from discussion earlier we
see that there isn't much difference with the currently available
mechanism. I still do not see any advantage over the currently
available system other than having an alternate way to do a thing
already can be done.

 I think this may not be a special requirement for my company, so
 letting .gitmodule record the common module hierachy should be a
 common requirement in a company environment.

Actually our company has a high modular structure, using maven makes
it easier to main and link modules. I would find an in place submodule
much more handy for such requirement.

 --
 Ping Yin


--
 To unsubscribe from this list: send the line "unsubscribe git" in
 the body of a message to majordomo@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557