Re: [PATCH/RFC v2] git-submodule: multi-level module definition
- From
Imran M Yousuf <imyousuf@gmail.com>
- Date
- Mar 6, 2008, 02:16 UTC
- Message-ID
- <7bfdc29a0803051816r752d3027yff83a78e1769216a@mail.gmail.com>
- In-Reply-To
- <46dff0320803051754o4b45222es524a62a7cac50b94@mail.gmail.com>
On Thu, Mar 6, 2008 at 7:54 AM, Ping Yin <pkufranky@gmail.com> wrote:
Show 47 quoted lines
> > 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.
Show 10 quoted lines
> > -- > 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