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

["Imran M Yousuf" <imyousuf@gmail.com>]

On Thu, Mar 6, 2008 at 7:54 AM, Ping Yin <pkufranky@gmail.com> wrote:
>
> On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  > Ping Yin <pkufranky@gmail.com> 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