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: David Reitter
Subject: Re: Emacs-24.4's release
Date: Tue, 14 Oct 2014 20:39:06 -0400

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

Thank you.  I am getting a little anxious about this. Do you consider the main 
conversion more or less done?

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

Yes. 

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

Since the old git repo (and the one before that) are part of my repo, we can 
just run it once (on mine).
Do you already have version stamps for everything  in the new one?

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

I have about 370 merges, the majority of which are merges from the mainline 
into one of my branches.

git rev-list --merges  --parents aquamacs3 --author=reitter >a3merges.txt
git rev-list --merges  --parents aquamacs2 --author=reitter >a2merges.txt

Some of these are merges against something else than the mainline, but I would 
think that your rewrite tool will leave rev-ids alone that cannot be translated.

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

This will definitely require your expertise… 

If all goes well, we should end up with the minimal repository necessary: no 
duplicate contents, I hope.
Right now I am carrying the first-ever git conversion of Emacs, plus the later 
official git mirror, along with my own changes.  I am obviously hoping to get 
rid of this old baggage and just have the new one.

Can I help this along by providing access to a big machine for the transfer?

- D


reply via email to

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