Re: State of the repository conversion

[Steinar Bang]

>>>>> Eli Zaretskii <address@hidden>:

> IOW, we need specific suggestions of workflows and procedures, rather
> than general references to possible ways of going about this.

Ok, here's how to make a local, er... remote

 1. Make an empty local repo
     cd ~/git
     git init --bare emacs-local
 2. Add it as a remote
     cd ~/git/emacs/
     git remote add local ../emacs-local
 3. Make a copy of the working directory:
     cd ~/git
     cp -a emacs emacs-copy

At this point the remote named "local" doesn't contain any branches, and
push and pull from either working directory will go against the same
remote (named "origin" if there is only one, and it has been given the
default name).

Now we'll make a branch in one of the working directories and push it to
the other, using the "local" remote (interesting terminology...).

 4. Make the branch and push it to local:
     cd ~/git/emacs
     git checkout -b sb-fix-annoying-bug
     git push -u local HEAD
 5. Fetch the branch into the other working directory
     cd ~/git/emacs-copy
     git fetch local
     git checkout sb-fix-annoying-bug

After 4 and 5, then sb-fix-annoying-bug will be a tracking branch in
both emacs and emacs-copy, but the upstream will be in "local" rather
than in "origin" (ie. push and pull when standing on that branch will go
to "local" rather than "origin").

Merge from sb-fix-annoying-bug to master will work fine, and can be done
from either working directory.

Downsides to a git repository backing multiple working directories, are:
 - 3 copies of the git repository on disk, rather than just one
 - An extra push needed after the commit in the workflow

Upside:
 - Only uses core git functionality, rather than a new and experimental
   feature 

(Personally I have learned to stay away from experimental git
features. Even if they work as advertised they may not be installed on
all git instances I use, and GUI tool support may be lacking)