best practices for multiple packages and submodules on git.d.o

[Stefano Zacchiroli]

On Tue, Mar 11, 2008 at 10:31:06AM +0100, martin f krafft wrote:
> > Even though I've never used that particular feature of git, it occurred
> > to me that the proper git solution for this are submodules [2].
> Are you sure? I suggest you read the discussion logged at

Eh, OK. That were indeed the issues I've called "submodules gotchas" in
my post. From that discussion I conclude that they are indeed quite
annoying, enough to prefer not to go for submodules for interrelated
packages. Thanks for the pointer.

So, what I conclude from that discussion + the colgit thread on the git
mailing list, is that the current best practice you are advocating is
several git repo in neighborhood directories, manager via mr. Is it
correct?

> The important thing to note is that the current commit of a submodule
> is a feature of the supermodule. If the submodule's repository gets a
> new commit, your submodule clone will *not* be updated until you
> explicitly update it. Once you did that, you *also* have to commit a
> change to the supermodule.

And, by the way, I do understand why this behaviour is reasonable/useful
in some scenarios, but I fail to understand why the dual behaviour of
following submodule heads is not implemented ...

> On the other hand, it might be really cool as soon as you have to
> deal with different suites. Imagine that ocaml in etch is all based
> on version 1.x (of ocaml-something) and in lenny, you want 2.x. You
> use maint/etch branches for each package, but that gets quite
> annoying after a while. So instead, you have a supermodule with
> references to all the commit IDs which made up etch, and you can
> keep track that way.

Uhm, frankly it doesn't seem to me the proper use case. I would use
branches for that, what do you mean with "gets quite annoying"?

> > Also, maybe more of a question for alioth.d.o admins, do
> > submodules works well with our current git.d.o infrastructure?
> Submodules are nothing but plain git repositories, so yes.

I feel I need to refine a bit more my question then (but only because I
haven't yet used git.d.o; feel free to point me to the fine manual). My
concern is what would I get from git.d.o. Is it just a directory
writable by some alioth group, on which I'm then free to "git init" as I
see fit?

If this is the case, I guess that the mapping of the solution you're
proposing to git.d.o is to have several .git directories rooted
somewhere under the group-writable directory I would get. Is it correct?
Would everybody be able to "git init" for new packages remotely without
needing to ssh on alioth?

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20080311/fcabf151/attachment.pgp