Hi Junio!
On Apr 8, 2008, at 11:43 PM, Junio C Hamano wrote:
"Avery Pennarun" <apenwarr@xxxxxxxxx> writes:
On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik <rvs@xxxxxxx>
wrote:
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
