Re: RFC: Making submodules "track" branches

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 9, 2010, 18:54 UTC
Message-ID: <AANLkTiknGcteTjrHWM02H2KOMMDPZKHY1w0ZOIswddFn@mail.gmail.com>
In-Reply-To: <4C0FB50F.3020403@xiplink.com>

On Wed, Jun 9, 2010 at 15:36, Marc Branchaud <marcnarc@xiplink.com> wrote:

> I wish I could come up with some way to reconcile clean branch-tracking
> submodules with historical consistency, but alas my imagination is so far too
> limited.  :(

I think the two concepts are fundimentally at odds with each other, and that that's completely fine.

Sometimes you're promiscuous enough with your history that you don't care about being able to go back in time, beyond checking out both trees as they were at some given time that is. As Johan and others point out above you could get around that with tags if you wanted snapshots.

I think we might actually have several different modes of operation:

  * Disconnected head + commit sha1 in the superproject's tree: This
   is what we have now.

  * The same, but make it branch aware. I've scripted this locally
    with the $toplevel patch to git-submodule that started this
    thread. But it could be expanded.

    It would be really neat for example to do:

        # Or some shorter way of doing this, perhaps even with
        # git-pull
        git submodule foreach 'git fetch'

        # Tells you that "submodule xyz which you've pinned to SHA1SUM
        # on the FOOBAR branch is 20 commits behind the upstream
        # FOOBAR branch"
        git status --submodules

    You'd still have to take action to update the module and move the
    SHA1SUM in the parent project, but something like this would make
    cases where you've e.g. included a lot of plugins in your project,
    and would like Git to tell you if they get new updates.

  * Branch-only: What I proposed in this thread. It's certainly not
    for everyone, but there's a lot of cases where you just want a
    quick meta-repository but aren't very interested in 100%
    historical consistency.

  * More? Actually if we're doing multiple strategies I see no reason
    not to e.g. include a foreign scm interface. That would be really
    useful to some projects that are in a SVN -> Git transition:

       [submodule "svn-lib"]
           ;; type defaults to git
           type = svn
           path = src/svn-lib
           url = svn://example.net/path/to/include
           ;; driver-specific attributes
           svn:revision = r54238