"Avery Pennarun" [off-list ref] writes:
On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik [off-list ref] wrote:
quoted
Agreed. But I guess I'd be less confused if "git submodule" didn't muck
with .git/config at all. Or are there any other consumers of the
information
that it puts there (except itself)?
That I don't know. If there aren't any others, then I agree, I'm not
sure what the whole .git/config messing is about.
Its actually the other way around.
In-tree .gitmodules is used to give hints to prime what is placed in
.git/config, which after initialized should serve as the authoritative
information on managed submodules as far as your repository is concerned.
"git submodule init" may be a handy way to do this "priming", but you do
not necessarily have to use it but instead manually adjust .git/config
yourself; this is so that you can configure remote url that is different
from what .gitmodules suggests to suite your local needs.
Although putting everything in a single repository could work, that does
not have to be the only way to work with submodules. In fact, the basic
submodule design is trying very hard not to force you to grab objects that
are needed for all submodules when you are cloning the superproject, as
not cloning nor checking out any submodule is the default.
Hi Junio!
On Apr 8, 2008, at 11:43 PM, Junio C Hamano wrote:
"Avery Pennarun" [off-list ref] writes:
quoted
On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik [off-list ref]
wrote:
quoted
Agreed. But I guess I'd be less confused if "git submodule" didn't
muck
with .git/config at all. Or are there any other consumers of the
information
that it puts there (except itself)?
That I don't know. If there aren't any others, then I agree, I'm not
sure what the whole .git/config messing is about.
Its actually the other way around.
Got it. But if you don't mind, I still would like to ask you a few
questions
to clarify some things.
In-tree .gitmodules is used to give hints to prime what is placed in
.git/config, which after initialized should serve as the authoritative
information on managed submodules as far as your repository is
concerned.
"git submodule init" may be a handy way to do this "priming", but
you do
not necessarily have to use it but instead manually adjust .git/config
yourself; this is so that you can configure remote url that is
different
from what .gitmodules suggests to suite your local needs.
Ok. Now I understand that .git/config is supposed to be the
authoritative
source of information on submodules. Yet we also have .gitmodules
to take care of. This leads to information duplication and makes me
believe that .git/config should be as much as sync with .gitmodules as
possible. Yet, even with the latest version of Git we don't have
"git submodule add" updating .git/config. So here comes the first
question:
* Do you consider this behavior to be a bug or do you a have a
reasonable
explanation for it?
Continuing in the same line of though as far as information
duplication goes,
here's my second question:
* Whenever .gitmodules and .git/config disagree on the URL for a
particular
submodule do you expect .git/config to always take precedence?
And finally, since from your explanation it appears that the only
reason for
.gitmodules existence is to "prime" the .git/config it seems that what
we're
trying to achieve is a way for Git settings that are usually part
of .git/config
to be resident within the repository itself. That would give these
setting
a benefit of percolating through clone/fetch/push operations, yet be
overridden by individual .git/config settings. And so I have my final
question:
* Has an idea of having a regular file (subject to having
history, etc.)
called something like .gitconfig at the top level of Git's
repository ever
been considered (implemented?). That way you a repository
maintainer
would be able to force a particular set of settings on all of
its clones
yet clones will be able to override then in .git/config if
needed.
Although putting everything in a single repository could work, that
does
not have to be the only way to work with submodules. In fact, the
basic
submodule design is trying very hard not to force you to grab
objects that
are needed for all submodules when you are cloning the superproject,
as
not cloning nor checking out any submodule is the default.
Indeed. This is a very beneficial setup for large projects. In fact,
what I'm working
on right now is a prototype of a build infrastructure that would be
smart enough
to import "cached" binaries of the build of a particular submodule if
the submodule
itself hasn't been checked out yet. SHA1 lets me do the versioning
properly and
once developers do checkout sources of any submodule the build system
will stop importing "cached" binaries and start build it for real. All
without developers
actually doing anything special.
Thanks,
Roman.
On Thu, Apr 10, 2008 at 11:43 AM, Roman Shaposhnik [off-list ref] wrote:
Hi Junio!
* Has an idea of having a regular file (subject to having history,
etc.)
called something like .gitconfig at the top level of Git's repository
ever
been considered (implemented?). That way you a repository maintainer
would be able to force a particular set of settings on all of its
clones
yet clones will be able to override then in .git/config if needed.
I like this idea, it's another common/special requirement just like
.gitignore vs. $GIT_DIR/info/exclude.
--
Ping Yin
On Fri, 2008-04-11 at 00:07 +0800, Ping Yin wrote:
On Thu, Apr 10, 2008 at 11:43 AM, Roman Shaposhnik [off-list ref] wrote:
quoted
Hi Junio!
quoted
* Has an idea of having a regular file (subject to having history,
etc.)
called something like .gitconfig at the top level of Git's repository
ever
been considered (implemented?). That way you a repository maintainer
would be able to force a particular set of settings on all of its
clones
yet clones will be able to override then in .git/config if needed.
I like this idea, it's another common/special requirement just like
.gitignore vs. $GIT_DIR/info/exclude.
Well, I guess if enough of us like it there's a chance it can be
implemented, right? ;-)
To some extent it seems that you've solved this particular issue for
submodules with your PATCH/RFC 3/7. Now, in a general case, if
git-config(1) can be patched to take into account one extra place
for retrieving options from (.gitconfig) it seems that
retiring .gitmodules completely would be just one benefit of many.
Other benefits would include propagating setting like most of the
core.* and quite a few other things I see listed in git-config(1)
man page.
It seems that the only downside here would be a need for a bit
of special handling when a setting needs to be recorded. Otherwise
it looks like a pretty clean and general idea.
Thanks,
Roman.