Quoting Heiko Voigt <hvoigt@xxxxxxxxxx> > On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote: >> On Tue, 5 Jan 2010, Jens Lehmann wrote: >> > Yes. This synchronization could be either obsoleted by only using >> > .gitmodules or automated. >> >> I start to wonder whether the insistence that .gitmodules' settings must >> be overrideable makes any sense in practice. > > I just read this and felt the need to comment. > > Yes, it definitely makes sense in practise to have it overrideable > otherwise we loose the distributed nature of git for submodules. > > Imagine you fork a project and you want to work with others on a change > that involves chaning a subproject. If you can not override .gitmodules > you can only work on the central repository. > > I am actually working like this in practise. I have a private clone of > all the subprojects msysgit has and commit/push locally first. Once I > sense the change is going to be useful for a wider audience I send it > upstream. This would be more uncomfortable if it is not overideable. > > But I know what you mean by the general confusion about manual updates. > So how about an approach like this: > > * clone will initialise all submodules in .git/config from .gitmodules > > * if a change in .gitmodules happens git scans .git/config for that > entry and in case nothing is there it syncronises the new one and > notifies the user. > > * if a change in .gitmodules happens and the entry before was the same > in .git/config we also automatically update that entry there. > > * In every other case we just leave .git/config alone. > > Did I miss anything? I think you should get the idea and that it could > get rid of the confusion caused by manual .gitmodule updates. > > cheers Heiko > > P.S.: Additionally (for my use case) we could add a "hint mechanism" > which allows git to "guess" a new submodules address. For example in > case I have all my local clones on "git@xxxxxxxxxxxxx:<modulename>.git". > Now when a new submodule gets seen in .gitmodules it will infer the > address from the hint configuration and not take the original one from > upstream. Thanks for sharing your thoughts. I find this discussion very interesting. I found this other discussion in the design area enlightening. http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621 It was before I started using git heavily and I don't see many people who were in the discussion yet in the current thread, but I think it is worth reading. P.S. A happy new year to everybody! -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ -- 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