"Lars Hjemli" <hjemli@xxxxxxxxx> writes: > On 5/28/07, Lars Hjemli <hjemli@xxxxxxxxx> wrote: >> This changes git-submodule in a few ways: > > Please don't apply the "Let .git/config specify the url for > submodules" patch, I'm having second thoughts ;-) > > Your design outline in > http://article.gmane.org/gmane.comp.version-control.git/48287 is > obviously superior, and I'd like to take a stab at it with something > like this: > > 1. 'git-submodule init' saves submodule name and suggested url from > .gitmodules into .git/config (submodule.$name.url) > > 2. 'git-submodule update' keeps the work tree updated for submodules > with five separate (and optional) operations: > a) git-clone --bare $url .git/submodules/$name.git > b) git-clone -l -s .git/submodules/$name.git $path > c) cd .git/submodules/$name.git && git-fetch > d) cd $path && git-fetch > e) cd $path && git-checkout $sha1 > > 3) 'git-submodule push' runs something like 'cd $path && git push > origin $branch', where $branch is found in .gitmodules > (path.$path.branch). > > A remaining issue is how to detect if step 2b is necessary if a > submodule is already checked out at the submodule path, but I guess > remote.origin.url in the checked out submodule would be the thing to > peek into. > > Also, step 2c/2d should obviously only be performed if the requested > sha1 isn't available, which should be trivial to detect with > 'git-cat-file -e'. > > Could this turn out to be an acceptable solution? Sounds sane to me, although I have to admit that I cannot really claim that I have thought things through in that strawman you quoted. - 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
