On Tue, Apr 26, 2016 at 4:19 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > 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. > Ok. That makes sense. > 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 something I definitely would like to be able to tell people. >> >> 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. > I like the idea of refs/submodules/config. > 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