Re: [PATCH 03/15] submodule add: label submodules if asked to

On Tue, Apr 26, 2016 at 3:50 PM, Jacob Keller <jacob.keller@gmail.com> wrote:

Good point! Yes that's exactly what we want.

Consider this:
We have:
    libA
    libB

Now libB grows a lot and someone decides to split it up into
2 libraries, so we'll have:
    libA
    libB-small
    libC-was-part-of-B

As libB (the big one repo containing all the code) was no open source, we can deprecate it fast and just keep developing in libB-small and libC-was-part-of-B. As we do only small changes at a time, we'll keep those 2 in the same label set, so the users can pick up the changes via

    git submodule update
    #  libB-small and  libC-was-part-of-B are in both the same group,
e.g. default
    # so they will be checked out.

When a bug is found in the future, you'd use `git bisect` to find it. In a repository with no submodules (analogy: think of splitting a file in two. Checking out older revisions will give the one old file, checking out newer revisions will give 2 new files.) that works great. With submodules we want to have the same properties.

    git checkout tag-before-libB-split
    git submodule update
    # get libB checked out

    git checkout tag-after-libB-split
    git submodule update
    # get libB-small and libC-was-part-of-B checked out

Ideally (read: in a later patch series), checkout will automatically checkout submodules for you if you have configured `submodule.updateOnCheckout`, such that switching old and new revisions will add or delete submodules automatically.

(Unrelated, but my thoughts on this) The remote url mechanism is broken with the .gitmodules file in some use cases: Consider there is an upstream "kernel.org" which hosts a repository with submodules. Now you want to mirror that superproject to "kernel.mymirror.org" and you start with

    git clone --mirror git://kernel.org/superproject

When the superproject uses relative URLs for the submodules, this will break your mirror, if you did not mirror them exactly with the same relative path. Then cloning from your mirror will result in broken submodule URLs.

So you would want an additional mechanism for URLs. Jonathan came up with the idea of having another configuration file in a refs/submodules/config branch which essentially allows to annotate/enhance the .gitmodules file.

So in such a configuration you could say:

    defaultRelativeURLBase = kernel.org
    [submodule."foo"]
        relativeURLBase = kernel.mymirror.org
        protocol = ssh
        # ssh as opposed to git:// which was inherited from the superproject

which allows finer controls of submodule/repository mirroring. As the refs/submodule/configuration is not part of the history of the superproject, mirroring can be done without changing history, but still having URLs changed to the internal mirror.

I am not sure. If it turns out to be a problem, maybe we can introduce a hook, that will be called on adding new submodules via lables?

Thanks, Stefan