From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:20
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.
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
> ...
quoted
[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 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.
--
Ping Yin
From: Imran M Yousuf <hidden> Date: 2016-06-15 22:44:20
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:20
Hi,
On Thu, 6 Mar 2008, Ping Yin wrote:
On Thu, Mar 6, 2008 at 7:18 AM, Junio C Hamano [off-list ref] wrote:
quoted
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
> ...
quoted
[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.
If it is _not_ always the case, .gitmodules is definitely the wrong place,
and $GIT_DIR/config is.
Just like we need "init && update", and not have "init" update implicitly,
like some people wish (who forget that other people might have other
wishes), we need to allow for different options here.
And as .gitmodules is _meant_ to be tracked, it is not the place to
express individual wishes differing from the colleagues' wishes.
Ciao,
Dscho
On Thu, Mar 6, 2008 at 10:32 AM, Johannes Schindelin
[off-list ref] wrote:
Hi,
> > 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.
If it is _not_ always the case, .gitmodules is definitely the wrong place,
and $GIT_DIR/config is.
Just like we need "init && update", and not have "init" update implicitly,
like some people wish (who forget that other people might have other
wishes), we need to allow for different options here.
And as .gitmodules is _meant_ to be tracked, it is not the place to
express individual wishes differing from the colleagues' wishes.
As an analogy, .gitignore is for colleagues' wishes and
.git/info/exluces is for individual wishes.
The same, .gitmodules is for colleagues' wishes and .git/config is for
individual wishes.
There are always common cases and special cases, so we need a machinsm
to support both of them.