Re: Emacs-24.4's release

[Eric S. Raymond]

David Reitter <address@hidden>:
> On Oct 14, 2014, at 5:54 PM, Eric S. Raymond <address@hidden> wrote:
> 
> > I could construct one, but this is not a request that has come up
> > before.  It would require a significant amount of new work.
> 
> Well, the thing is, I don’t know how to convert my downstream
> project, which has 10 years worth of its own development and regular
> merges against two version of the git mirrors, the later one quite
> official and GNU/FSF sanctioned.

Ah, right, you're the Aquamacs guy.  I haven't given up on heelping you 
accomplish what you want, but I didn't see a lot of point in pursuing
it util the main conversion is done.

> I might cut off all history prior to 2005, “flatten” the merges somehow (so 
> that they lose their Emacs-side parent), and then re-connect to the new Emacs 
> repository with a merge right at the point where you do the conversion.
> 
> This will destroy a lot of history on my end, which is lamentable.

Let's try to avoid that.

What you need, then, is a mapping from the hashes corresponding to your
merge points to the merge points in the conversion?  To, I take it, be 
used later when we try building a repo based on the new official git
that includes your work.

That is doable. Here's how I would approach it:

1. Write a script that use git log to generate a file of lines
pairing each hash with its version stamp.

2. Run it on the old git repo.  Then run it on your repo.

3. Write another little script to join these reports, using
version-stamp as a primary key.

4. You then need to give me a list of your merge links from the
old repo - that is, all the pairs of parent/child hash pairs that
represent merges into your repository.

5. Then we sanity-check.  If either the set of parent hashes or the
set of child hashes is paired with any duplicate version stamps (very
unlikely but theoretically possible) life gets complicated.  Let's
assume that doesn't happen.

6. If life has not become complicated, we now have an unambiguous
representation of the cross-repository links as both hash pairs
and version-stamp pairs.

7. Now (he said, taking a deep breath) we write another script.
It walks through your repository, emitting Aquamacs commits as 
git-import-stream objects in which some merge links (those that point to
parents outside your branch) are version stamps rather than marks. 

8. reposurgeon has a variant graft operation that can merge this
stream into a copy of the new git repo. I wrote this specifically
for your use case.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>