Re: git commit/push and VC

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > >   . do we want to explicitly recommend 2 different clones, one each
 > > >     for master and the release branch? there's nothing in the
 > > >     instructions about this, or about working with 2 divergent
 > > >     branches in general

 > > Unless you're really working all the time in parallel on both branches
 > > I'd say this setup is more trouble than it's worth.

 > I personally am working on both branches in parallel, yes.  Many
 > others do, too.  Bugfixes go to one branch, new features to the other,
 > people report bugs on this or other, etc.  Bootstrapping each time,
 > which takes a couple of minutes, is annoying.  And then you sometimes
 > want to compare what the two binaries, one from master, the other from
 > the release branch, do in the same situation.
 > 
 > But that's me, and I already know how to solve this.  I'm asking what,
 > if anything, do we want to recommend.

I would say either go with *your* gut feeling, or if you prefer,
somebody else you trust. ;-)  You could also present several scenarios
with expected issues (people can probably judge the merits for
themselves, but the downside of messing up a personal repo is quite
large).  I can think of the following:

1) single clone, multiple out-of-tree build directories (this is what
   I use).  Disadvantages: IIRC Emacs uses the same "link lisp/ ->
   $srcdir/lisp" strategy that XEmacs does, so bootstrap takes a long
   time, and the first make after switching is likely to take a long
   time even if you don't bootstrap (because checked-out files all
   appear to have been touched).  There will be several emacs binaries
   associated with the clone, so there is potential for confusion
   between the running Emacs and the checked-out version.

2) single clone, in-tree build.  Disadvantages: as (1), but even more
   so, except that it's easier to keep emacs in synch with the sources
   as there's only one binary in existence.

3) multiple clones, build per clone (I don't think it much matters
   whether it is in-tree or not, and people who use out-of-tree builds
   probably have other reasons for doing that already, and they'll
   know what they are doing).  Disadvantages: one of the clones will
   be used for "stable" -> trunk merges and reverse cherry-picking,
   and you need to keep track of which one.  You also need a lot more
   VCS operations to keep them in synch.

4) single repo, multiple workspaces (use GITDIR variable, for
   example).  Disadvantages: not well-supported by git AFAIK, so the
   user has to keep track of the global branch.

Maybe you shouldn't mention (4).

Steve