On Fri, 28 Jul 2017 09:15:46 +0200 Christophe de Dinechin <dinechin@xxxxxxxxxx> wrote: > > On 27 Jul 2017, at 17:07, Marc-André Lureau > > <marcandre.lureau@xxxxxxxxxx> wrote: > > > > - Create top-level repository with all others repositories as > > submodules (if we use 'spice-server', that one would be called > > 'spice') * > > > > Isn't this already the case? https://cgit.freedesktop.org/spice/ > > If that’s the case, it’s cool. But it looks like a group of > repositories in freedesktop, more than a repository with submodules. > What is the git clone command to clone that top-level repo? > > Having a top-level repository makes work on branches that impact > multiple components easier. Case in point today: streaming impacts > server, protocol, agent, client, etc. So being able to easily switch > to the “stream” branch and update protocol, agent, client and server > in one command (ok, two, git checkout following by git submodule > update) is useful. > > > > > How you really mean "git submodules".. Eh, what's the point? Sounds > > very wrong and useless to me, it will be constantly outdated.. > > Write a script instead? > > What I really mean is something like this: > https://gitlab.com/c3d/spice. I did that quickly, but ultimately, I’d > like to have READMEs and global build scripts, to put spice-space > repositories under “docs”, that kind of things. > > > > > > - Make spice-protocol a submodule of modules that use it > > > > We have been there before with spice-gtk/spice-common, and it was > > reverted. > > But spice-common is still a submodule, so I don’t understand why you > bring it up. Unless you are talking about removal of spice-protocol > in spice 0.12.6 ? If that’s the case, I don’t see much of a > discussion around > https://lists.freedesktop.org/archives/spice-devel/2015-August/021312.html, > just the justification “it’s stable, so we don’t need to bundle it”. > I looked in the mails for the three months prior to that looking for > clues as to why submodules were such a problem, didn’t find any. So I will list some. - git does not automagically clone submodules. So the instructions on gitweb for cloning are wrong for repositories with submodules. People sometimes even forget to mention the submodules in README/INSTALL files - git does not automatically update submodules so they get outdated unless you mind to update them by hand or create an alias - git does not automatically push to submodules so they get out of sync unless you mind to push them by hand or create an alias/script - git does not archive submodules so creating a snapshot/release tarball of a repository with submodules is a nigtmare Until repositories with submodules are first class citizens with all the support plain repositories get in git I am strongly against submodules. > > > The main issue was that every project ended-up bundling > > spice-protocol. > > Well, that’s sort of the point of submodules. I don’t see how this is > a problem. > > > (and others keep complaining about various submodules issues) > > Let me guess: dangling SHA1 because people kept forgetting to push > changes to the submodule? Hmmm, but if the module is stable, that > should practically never happen. > > > Since spice-protocol is very stable, it's actually best to keep it > > standalone. > > From a git perspective, this sentence makes no sense whatsoever. Most > submodule-related issues tend to occur with active submodules, not > with stable ones. That goes both ways - if the modules are stable you can as well unbundle them. For the rare cases you need to change all at once you can create a separate checkout/install in a prefix. Thanks Michal _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel