On Mon, Mar 31, 2008 at 5:29 AM, Eyvind Bernhardsen <eyvind-git@xxxxxxxxxxxxxx> wrote: > On 31. mars. 2008, at 01.03, Avery Pennarun wrote: > As I tried to explain, all the automatic push solutions I could come > up with were flawed, so I decided not to use submodules at all and > just have the build tool check out every module (that's what we > currently do with CVS, so it's the easy way out anyway). I even *use* git-submodule and had to modify my build scripts because "git submodule init" and "git submodule update" don't seem to kick in automatically for some reason. The ideal situation would be to have git just manage the version control without having to babysit it, of course. That's hard to do in the general case, but should be quite possible in the limited situation that I'm proposing in this thread. > If I understand you correctly, you want to be forced to create a > branch and push to that? I don't think that works well with many > developers pushing to a shared repository (my situation), Hmm, this is curious. If you're *not* using submodules, then I don't think you can push successfully without being on a branch, can you? So the suggestion merely extends this behaviour to submodules. (To be more precise, 'git push' seems only to be able to push branch heads. When you're not using git-submodule, commits are by default attached to branch heads, so this doesn't cause a problem. If you disconnect your HEAD, trying to push will silently do nothing, because it'll push some other branch head that hasn't changed, or maybe no branch at all. But with git-submodule, the *default* is a disconnected HEAD, which is too dangerous. I propose to simply have it fail out in this case.) If you 'git checkout -b branchname' inside a submodule, then 'git push' will do the right thing, so I'm not sure what you'd want to be more automagical than that. > If you have local changes committed in a submodule that is updated by > a pull in the main module, "submodule update" will silently overwrite > them. I was wrong, though, because you can fix that just by making > "submodule update" error out when a submodule doesn't have its HEAD > where the main module thinks it should be. Shouldn't "git merge" get a merge conflict if you've made a checkin that changed the submodule pointer, then try to pull someone else's checking that changes the submodules pointer to something else? It would seem there's no better option than that. While we're here, it's inconvenient to have to call "git submodule update" at all when there *isn't* a conflict. It should always be safe for git checkout or git merge to do that for you, no? Thanks, Avery -- 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
