Re: Emacs-24.4's release

[David Reitter]

Hi Eric,

I’d like to pick up where we left off last year, now that the dust has settled 
with the Emacs transition.
Can we discuss how to get Aquamacs transitioned to the new repository?
More info by e-mail - I sent you two e-mails earlier in the week.   

- David




> On Oct 14, 2014, at 6:49 PM, Eric S. Raymond <address@hidden> wrote:
> 
> 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>