Re: RFC/RFH submodule handling in big setups

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Jan 7, 2008, 20:59 UTC
Message-ID: <20080107205905.GB19728@pvv.org>
In-Reply-To: <20080107200756.GA20892@efreet.light.src>

On Mon, Jan 07, 2008 at 09:07:56PM +0100, Jan Hudec wrote:

Show 16 quoted lines

> On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:
> > 3. each time you push a submodule, do a merge ours to a
> >    "internal-submodule-tracking" branch, and push to that. Something
> >    like this in other words:
> > 
> >      git fetch origin internal-submodule-tracking
> >      git merge -s ours origin/internal-submodule-tracking
> >      git push origin internal-submodule-tracking
> >      git reset --hard HEAD^1
> > 
> >    Issue: feels wrong somehow?
> 
> Only one thing feels wrong here -- the merge -s ours. For one thing, the
> commit is probably descendant of what was in the internal-submodule-tracking
> branch (the branch name should actually have product2 in it's name).
> If it is not, you should not artificially make it so, but rewind the branch.

The idea of the branch is to not have to make thousands of tags as time passes, just to have a branch that refers to all the commits that the supermodule refers to in the submodule.

The internal-submodule-tracking branch should look like this:

        / ... etc
       m
      / \
     m   o-commit 3  
    / \
   m   o-commit 2
  / \
 .   o-commit 1

Where all the "m" commits are just dummy merge commits, the contents are of no consequence (hence the "merge -s ours" that should always silently go through). commit 1, 2 and 3, ... are the interesting ones, they are the sha1s the supermodule refers to in the submodule. They may or may not have any relationship to eachother. If they _do_ have a realtionship to eachother, this will be tracked in some other branch in the submodule.

So the purpose of the internal-submodule-tracking branch is: Have a branch to push to (you cannot just push a sha1 to nowhere), have something that refers to the sha1 so that it will not be pruned away, and have something that refers to the sha1 so it will actually be _fetched_ by git fetch.

> But as Junio already told you, you should really manage the subproject like
> a project (because it is a project), so the change should get to a topic
> branch where the other superprojects can look at the change and decide
> whether they want it or not.

See another mail I wote, I don't want to manage the subproject like a separate project (it isn't).

- Finn Arne