Re: git submodules

From: Pierre Habouzit <madcoder@debian.org>
Date: Jul 29, 2008, 08:37 UTC
Message-ID: <20080729083755.GC32312@artemis.madism.org>
In-Reply-To: <20080729082135.GB32312@artemis.madism.org>

On mar, jui 29, 2008 at 08:21:35 +0000, Pierre Habouzit wrote:

Show 6 quoted lines

>   * a way to remember where you want to push changes you do in the
>     submodule to. That's a bit like branch tracking, but not quite. This
>     is required so that we can (and I strongly believe we want that in
>     the end) make many porcelain commands act on the full
>     (super+sub)modules in a unified way, somehow hiding the submodules
>     boundaries.

<snip>

> 
> 
>   * What you "track" must be a per supermodule branch thing, so that if
>     you do things like that:

<snip>

  In fact, nowhere I used the name of the current submodule branch in my
examples, so maybe we don't really need it. What we need though, is a
way to tell where the submodules are pushed to, IO what they (try to)
track remotely, IOW of which remote reference they should always be a
parent.

  Such an information is probably to be put in .gitmodules, this way,
you have the per-supermodule-branch setting I would like to see. And
then one would not care about the submodules be in a detached HEAD
because I believe those scenarii work well:

  * If you do no changes in the submodules, all just works like it does
    now.

  * If your only work in the submodule is to refresh its state to the
    tip of what it currently track, then well, we probably want a git
    submodule command for that, and no further ado is done.

  * If you just want a simple fix to go in the submodule, work from your
    supermodule, as if there was no submodule. git-commit your changes
    (which with a submodule aware git-commit would be transparent), then
    you can push your work. And in the worst case scenario where you
    cannot push because it's not a fast forward, you would fetch, merge
    and push again.

    You don't really need a name for the submodule, even if you want to
    reset to the state before the merge because you screwed it, as
    basically, git-reset would _also_ be submodule aware and DWYM
    without an explicit reference for the submodule.

  * If you have heavy works in the submodule, then you probably will
    setup many submodule topic branches, work inside of it like you
    already do, and the extra step of reattaching the HEAD somewhere is
    not as bad as it is with (3) as it's a tiny overhead compared to all
    you're going to do with your topic branches.

So okay, let's scratch this "automatic reference" thing, I see its limits now, so what about having a .gitmodule entry look like:

    [submodule "$path"]
	path = "$path"
	url = git://somewhere/
	tracks = master

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org