From: Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Date: Mon, 31 Mar 2008 10:05:20 GMT
Subject: Re: git-submodule getting submodules from the parent repository
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:

> 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.

>> 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.

>> 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