[Spice-devel] Survey of repository preferences

[msuchanek]

On Fri, 28 Jul 2017 09:15:46 +0200
Christophe de Dinechin <dinechin at redhat.com> wrote:

> > On 27 Jul 2017, at 17:07, Marc-André Lureau
> > <marcandre.lureau at redhat.com> 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