Re: Git transition checklist

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

Eli Zaretskii writes:

 > I guess we have a consensus, then.  I think Stefan also suggested
 > separate repositories.

 > So would someone "in the know" please update the Wiki with the
 > instructions how to set this up and what the workflow would look like
 > for working on the trunk and a release branch  in this way?  The main
 > jobs to be covered are, I think, (a) updating each branch from
 > upstream and (b) merging and/or cherry-picking commits between the two
 > branches each one of which is in a separate repository.  TIA.

No, both branches must be in the same repository to perform those
operations.  The only thing git can do between repositories is fetch
objects that are reachable from a reference.  Merging branches
requires that both be present in one repository; the resulting DAG
structure can then be fetched and merged into other repositories.
Similarly with cherry-picking.

What this implies for Emacs release workflows I can't say because I
don't know how the Emacs release workflow works, specifically who
commits the merges and cherry-picks.

The issue about multiple repositories is about whether a single
developer's feature branches should share an object database (at least
that's what I've been talking about, and I believe Andreas too).  The
conclusion is that they shouldn't, but this will result in a certain
number of objects duplicated in several local repos.  However,
reducing that duplication by --share'ing is not worth the risk of gc
in the origin repo corrupting the feature branches (because the origin
repo doesn't know about those branches).

 > Btw, I think git can use something called "alternates" instead of hard
 > links?  Is this relevant?

Yes, that's precisely what --shared does.

 > >  > Copying commits between clones is straight forward with git fetch.
 > > 
 > > True but I doubt Glenn and Eli are worried about that.
 > 
 > ??? Merges and cherry-picks between the release branch and the trunk
 > happen all the time, as long as the release branch is active.

Sure, but you won't be using git fetch directly to do that.  You'll
use git pull or git push, which do any necessary fetching implicitly.
What Andreas is talking about is reorganizing the object databases in
a way that won't affect the branch structure visible in the origin or
in the clone.  (At least, that's what I think he's talking about.)