Re: What's cooking in git.git (topics)

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

On Tuesday 22 April 2008, Ping Yin wrote:
> >  A reason you did not mention is security:
> >  You never want your .git/config to be changed behind your back, which
> >  effectivly is the case when using the versioned .gitmodules information
> >  (similar problem as with a .gitconfig in-tree).
> 
> As discussed in another thread about in-tree .gitconfig, security
> issues only arise on limited configuration entries. However, there are
> no entries in .gitmodules falling into any of these entries.

Hmm... At least, it can be very annoying when git fetches data from repositories
you did not expect, only because submodule URLs change via this
fallback mechanism. Perhaps it is a little far reached, but suppose a project
changes its URL, and the old one becomes occupied by a malicious person.
The problem is that the URL with the now malicious repository is bound in the
history of the project. For sure, you do not want to fetch from that old repository
by accident, after you did a checkout of an old commit. And there would be no
way to protect other people from this malicious repository other than rewriting
the whole history.

> >  Another one:
> >  From a design point of view, submodule URLs are project meta information
> >  unrelated to source history. So, actually, I think it was wrong to put
> >  submodule URLs (even hints only) into the versioned .gitmodules files (*).
> 
> But now it actually acts as hints and we don't find a better way. I
> just propose that the hints become the good default.

For me this sounds like: Now that we have made this bad decision, it does
not matter to make it even worse.

What was the motivation for this fallback mechanism?

In any way, it is preferable to always use the correct URL for submodules.
Thus, when the URL ever changes in the projects livetime (covered by
git history), you want to have the correct URL in your .git/config
(not to accidently use the wrong URL when checking out an old commit).
But then, the fallback mechanism does not trigger anyway.

> >  The main reason for .gitmodules is to store submodule information which
> >  has to be in sync with commits, such as a submodule name related to some
> >  path where the submodule happens to be checked out in a given commit, and
> >  also related to some config entry holding the URL to allow for fetch/pull.
> >  The idea is that submodules have an identity in the supermodule (in contrast
> >  to files in git), such that related configuration keeps valid when moving
> >  submodules around. This needs simultanous adjusting the path attribute in
> >  .gitmodules when a submodule is moved.
> 
> If we go back to a old HEAD or switch to another branch with changed
> path for a submodule,  what should 'git submodule update' do?
> I think entries in .gitmodules should take precedence.

Of course. It makes no sense to have submodule path configuration in .git/config,
as it has to be in sync with the current commit. That has nothing to do with
precedence. The same is true for .gitattributes, for example.

> So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
> authoritative.

No.
These are totally different types of configurations.

Josef