Re: The Gnus repository is switching to Git as of 2010-04-19

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > I don't like the way submodules work.  They are good for independent,
 > fairly static externals but for synchronizing two repositories I think
 > they'll be a pain.

Sure, but you're in for pain anyway since Gnus is a subset of Emacs,
not a subtree.  That is, Gnus-maintained features are spread across
several subdirectories of Emacs, while those Emacs subdirectories also
contain non-Gnus content.  Gnus contains lisp and etc directories
directly, while (I presume) Emacs contains lisp/gnus and etc/gnus
directories.

I can think of several ways to deal with this, but none of them are
very attractive.  Of them, I personally would use git submodules
because even though I'm sure I'd screw them up occasionally, there
would be an exact record of how they got screwed up.  The precise
semantics of submodules makes the task eminently scriptable, too, so
I would expect not to make the same mistake twice.[1]  YMMV<wink>

*What I would do if I were you* is lobby for a new subtree, "packages",
of the Emacs tree, and just plop Gnus into that, with its Lisp and
support files all under packages/gnus.  Add a make rule which puts
appropriate Gnus autoloads into the loaddefs or whatever Emacs uses,
to find Gnus' Lisp and data in there.  (Directory symlinks would work,
as in XEmacs' "symlink farm installation" option, but aren't
acceptable as long as systems that can't symlink easily are
supported.)  The way you're going, you're just making the same mistake
XEmacs made with its package system (having the installed tree look
different from the source tree), except that you're going to have more
pain than we do because of the possibility of shooting off both your
feet.  XEmacs packages has only one source tree, so even though the
installed structure is different from the source structure, at least
all the hackers are on the same page.  This isn't going to be true for
Gnus.

 > There's some unpleasant caveats at
 > http://book.git-scm.com/5_submodules.html plus they are really easy
 > to screw up.

Sure.  It will be work to make them work.  But I'm fairly sure you can
do it.  My point in replying to Stefan is that there's no standard way
to do it in Bazaar yet, and the chances are high that the standard,
when it appears, will yank the rug out from under existing practice.

 > SJT> Maybe.  I worry about ghost revisions appearing when you do a git->bzr
 > SJT> sync, and that's where they are most likely since git users branch
 > SJT> with abandon then abandon the branches, while it's no fun to try to
 > SJT> work with Bazaar that way.  Note that ghost revisions causes nasty
 > SJT> bugs in bzr as recently as a few weeks ago.
 > 
 > Using git-bzr from http://github.com/kfish/git-bzr, it seems you can
 > only push to a single branch, will that still cause problems?  I think
 > the Gnus repository is pretty unlikely to branch with abandon, in any
 > case.

Visibly, no.  But you have no control at all over what your developers
do privately.  Once merged and pushed, those branches have no names in
the public repository, but they still exist there!

I don't understand how ghost revisions (revisions referenced as
parents by revisions in the repo, but which themselves are not present
in the repo) can exist at all in a DAG-based system.  One may hope
that because git doesn't permit that, they won't exist in the bzr
mirror of your git tree, and that's actually probably a good bet.  But
I can't say it can't happen; it's your privilege to place your bets
here.<wink>

 > If Yidong, Stefan, and others are concerned about ghost revisions, we
 > can simply prepare the Gnus -> Emacs synchronization as a patch and
 > submit it through the usual channels or apply it manually ourselves in
 > isolation within Bazaar.  This will probably be the modus operandi at
 > first anyhow.

Yup.

Footnotes: 
[1]  NB. the synch tree would be owned by a special user, and only the
update scripts would be allowed to touch it.