Re: Git transition checklist

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: esr@thyrsus.com,
>     Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 09 Jan 2014 23:30:35 +0900
> 
> On balance, I guess it is better to avoid the --shared option.

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.

> Except: what about Windows filesystems?  I have no idea if they
> implement hardlinks properly

Hard links are supported on NTFS.  I didn't yet try cloning locally
though, so I don't know whether there are Windows-specific problems
here.

> (I gather the semantics of symlinks are somewhat different).

The semantics of symlinks are almost identical, but creating a symlink
is a privileged operation on Windows, so use of symlinks is not a good
idea.

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

>  > 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.

Btw, one other task that should be accomplished before the switch is
how and what will we merge between the two branches.  We use
admin/bzrmerge.el with bzr, and the way that works allows to make a
release branch from the trunk by merging.  The corresponding
gitmerge.el, if it is needed, or procedures that will replace it if
not, should probably allow similar capabilities.