From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Emacs-24.4's release Date: Tue, 14 Oct 2014 18:49:27 -0400 Organization: Grafting Aquamacs Message-ID: <20141014224926.GA18117@thyrsus.com> References: <20141014215424.GA17044@thyrsus.com> <5826765D-B430-4CCF-BA9D-B38DE1BD04C4@gmail.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1413326998 4398 80.91.229.3 (14 Oct 2014 22:49:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Oct 2014 22:49:58 +0000 (UTC) Cc: Stefan Monnier , "emacs-devel@gnu.org developers" To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 15 00:49:52 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XeAue-0001rY-4T for ged-emacs-devel@m.gmane.org; Wed, 15 Oct 2014 00:49:52 +0200 Original-Received: from localhost ([::1]:40722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeAud-0000Ti-Qy for ged-emacs-devel@m.gmane.org; Tue, 14 Oct 2014 18:49:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeAuM-0000TF-LV for emacs-devel@gnu.org; Tue, 14 Oct 2014 18:49:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XeAuF-0001No-PK for emacs-devel@gnu.org; Tue, 14 Oct 2014 18:49:34 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:39162 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeAuF-0001Nb-KH for emacs-devel@gnu.org; Tue, 14 Oct 2014 18:49:27 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 25DB1383A4A; Tue, 14 Oct 2014 18:49:27 -0400 (EDT) Content-Disposition: inline In-Reply-To: <5826765D-B430-4CCF-BA9D-B38DE1BD04C4@gmail.com> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175382 Archived-At: David Reitter : > On Oct 14, 2014, at 5:54 PM, Eric S. Raymond wrote: >=20 > > I could construct one, but this is not a request that has come up > > before. It would require a significant amount of new work. >=20 > Well, the thing is, I don=E2=80=99t 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=20 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, =E2=80=9Cflatten=E2=80=9D th= e 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 wher= e you do the conversion. >=20 > 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=20 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=20 git-import-stream objects in which some merge links (those that point to parents outside your branch) are version stamps rather than marks.=20 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. --=20 Eric S. Raymond