Re: git-submodule getting submodules from the parent repository

From: Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Date: Mar 31, 2008, 10:05 UTC
Message-ID: <62D616ED-83C8-4AB7-9113-98688732DE09@orakel.ntnu.no>
In-Reply-To: <47EFF5BE.7030502@vilain.net>

On 30. mars. 2008, at 22.19, Sam Vilain wrote:

Show 9 quoted lines

> Eyvind Bernhardsen wrote:
>> Well, the point of "submodule push" was to avoid having to push in
>> each submodule manually; not enforcing the requirement that commits  
>> in
>> submodules must be publicly available before pushing from the main
>> module is a recipe for disaster, or at least annoyance.  And nobody
>> likes an annoying git.
>
> ok.  so, refuse to push without forcing, don't do something dumb.

I think you misunderstood: what I'm saying is that submodules' _current_ behaviour is annoying, since you're guaranteed to forget to push a submodule before pushing the main module at least once. My attempt to solve that became too complicated, so I dropped it, and since the current behaviour is annoying, I gave up on submodules entirely.

Show 8 quoted lines

>> Pushing to a branch works except that I couldn't figure out what to  
>> do
>> if the push doesn't succeed, ie, the branch has advanced on the  
>> remote
>> end.
>
> It's simple.  You just fail and tell the user what happened, and let
> them decide what to do.

Sure, that solves the annoyance problem, but I wanted something more automatic.

Show 10 quoted lines

>> It's a reflog, not a branch, because a submodule can be changed to a
>> different branch, rewound, etc between commits in the main module;
>> there's no requirement that the old commit is in the new commit's
>> history.
>
> If it is a rewind there is no issue, because you don't even need to  
> push.
>
> But again it comes back to - let the user sort it out, don't try to be
> too clever.

Yep, my problem was wanting to be cleverer than my limited git skills will allow.

-- 
Eyvind Bernhardsen