From: Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Date: Sun, 30 Mar 2008 19:50:24 GMT
Subject: Re: git-submodule getting submodules from the parent repository
Message-ID: <C38585A9-F09C-4A5B-8E72-6F3127DB2BB9@orakel.ntnu.no>
In-Reply-To: <47EFD253.6020105@vilain.net>

On 30. mars. 2008, at 19.48, Sam Vilain wrote:
> Eyvind Bernhardsen wrote:
>> I solved that by adding a "submodule push" that pushes the detached  
>> head
>> of each submodule to its own ref ("refs/submodule-update/commit- 
>> $sha1",
>> imaginatively).  I also made "submodule update" try to fetch that ref
>> when looking for a sha1.
>
> Hmm, a reasonable decision, but I think it would be better to force  
> the
> user to choose which branch they want to push to.  Leaving breadcrumbs
> in the refs/ space like that is best avoided.

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.

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.  That's a problem if more than one module references the  
submodule or there are multiple branches in the main module.

One solution that occurred to me was to have a branch in each  
submodule for every main module and branch.  A branch name would be  
provided for each submodule in .gitmodules, used by "submodule push"  
but not "submodule update".  In this case, if the push to the branch  
fails, the main module branch is probably behind too.

This seemed like a good idea, but it's racy.  If two simultaneous  
"submodule push"es try to push to the same branch on a submodule, one  
of them will be rejected, but it might already have updated branches  
on other submodules.  Ick.

I briefly toyed with creating tags named after the main module and its  
branch, with the submodule sha1 included for good measure, but that  
leaves a _real_ mess in refs/tags.  Figuring out that I could use refs/ 
submodule-push instead seemed like an epiphany at the time.


As an aside, my mental model of what the submodule needs is a  
fetchable reflog for every main module and branch that uses it,  
containing the history of commits used by that module/branch.

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.  You actually don't want to fetch the whole thing, but you  
have to be able to fetch every sha1 contained in it, by sha1.

...so that's what refs/submodule-push is supposed to look like.  You  
might need to squint a bit.

> Indeed - it can only become "fit for public consumption" if people
> submit their usability enhancements!

True :)  I still have no idea how to figure out which submodules are  
dirty, though.  Solving that will enable a safe "submodule update",  
which I think is more important than "submodule push".
-- 
Eyvind Bernhardsen