Re: git-submodule getting submodules from the parent repository

["Avery Pennarun" <apenwarr@gmail.com>]

On Mon, Mar 31, 2008 at 5:29 AM, Eyvind Bernhardsen
<eyvind-git@orakel.ntnu.no> 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