On Tue, Apr 26, 2016 at 3:50 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote:
> On Tue, Apr 26, 2016 at 1:50 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
>> When adding new submodules, you can specify the
>> label(s) the submodule belongs to by giving one or more
>> --label arguments. This will record each label in the
>> .gitmodules file as a value of the key
>> "submodule.$NAME.label".
>>
>
> Ok so labels will be in the .gitmodules file. This means that if we go
> back in history using git bisect or something similar, we'll
> potentially change what the default submodules are for example?
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.
>
> This is sort of why having some submodule data appear in the
> .git/config file is useful since it helps keep things like the remote
> url safe from being updated when doing this sort of thing.
(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 labels will be that important in this case?
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
>
> Thanks,
> Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html