On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote: > 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. It is always bound now without the fallback patch :) > 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. I wonder how the *malicious* repository can hurt us since only the commit recorded in commit of the super project will be checked out. > > > > > 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. I should be like: Now that we have made a bad decision (if it is), we have to improve it to make life better before we can find a better solution. > > 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. I havn't found yet how an incorrect URL can hurt us. The worst case i can imagine is the failure of "git submodule update". Two of the most common cases which can result in an incorrect/stale url is * the repository has been moved to another machine * the directory structure of upstream repositories has changed However, there are also cases that the old version of url in .gitmodules is correct. Think about the case that the reposotory maintainer has decided to replace current submodule with a totoally different one. In this case, when back to the old HEAD, the url in .gitmodules is correct while url in $GIT_DIR/config is incorrect. So, when error happens, we can't judge which url is correct. So just let the user make the decision by refering the change history of .gitmodules or asking the repository maintainer. -- Ping Yin -- 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
