emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs-24.4's release


From: Jan D.
Subject: Re: Emacs-24.4's release
Date: Thu, 05 Feb 2015 15:56:10 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]