Re: Emacs-24.4's release

["Jan D." <jan.h.d@swipnet.se>]

Hi.
A while back there was some copyright discussion when I took some code 
from Aquamacs, so I don't do that anymore.  Has this been resolved, i.e. 
has all contributors to Aquamacs signed papers?

	Jan D.

David Reitter skrev den 2015-02-05 01:31:
> 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 <esr@thyrsus.com> wrote:
>>
>> David Reitter <david.reitter@gmail.com>:
>>> On Oct 14, 2014, at 5:54 PM, Eric S. Raymond <esr@thyrsus.com> 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>
>