Emacs-24.4's release

Emacs-24.4's release

[Stefan Monnier]

Barring any major problem encountered til then, we intend to cut the
24.4 release candidate this Friday, and (assuming nothing went wrong
with that candidate) make the release official the subsequent Monday.

Could someone try to write up a release announcement (i.e. mostly look
at the NEWS and condense it into by selecting the ~10 most noteworthy
new features)?


        Stefan

Re: Emacs-24.4's release

[Glenn Morris]

Stefan Monnier wrote:

> Barring any major problem encountered til then, we intend to cut the
> 24.4 release candidate this Friday, and (assuming nothing went wrong
> with that candidate) make the release official the subsequent Monday.

PS Just in case there was any doubt, this means:
after the release candidate is made, do not commit ANYTHING to emacs-24
without asking here first.

In fact I would really appreciate it if people do not commit anything to
emacs-24 after 0000 UTC on Friday.

Re: Emacs-24.4's release

[Stefan Monnier]

> PS Just in case there was any doubt, this means:
> after the release candidate is made, do not commit ANYTHING to emacs-24
> without asking here first.
> In fact I would really appreciate it if people do not commit anything to
> emacs-24 after 0000 UTC on Friday.

Right, I forgot to mention that this means that people should not commit
anything to emacs-24 from now on, unless it's really super obviously
safe, or they get an explicit go ahead from Jan, Eli, Handa, Glenn,
or myself.


        Stefan

Re: Emacs-24.4's release

[Eric S. Raymond]

Stefan Monnier <monnier@IRO.UMontreal.CA>:
> Right, I forgot to mention that this means that people should not commit
> anything to emacs-24 from now on, unless it's really super obviously
> safe, or they get an explicit go ahead from Jan, Eli, Handa, Glenn,
> or myself.

Sounds like a good time for me to update the recipe for the full 
git conversion.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-24.4's release

[David Reitter]

Eric,

On Oct 14, 2014, at 2:28 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Sounds like a good time for me to update the recipe for the full 
> git conversion.

Will there be a mapping that aligns rev-ids from the old official git mirror to the new git repository?

I tried loading the Emacs repository into reposurgeon.  I ran out of time/disk space - can you comment on how large the temporary fast-export file is, and how long it takes to export it?

Thanks,
David

Re: Emacs-24.4's release

[Glenn Morris]

Please start a new thread for any git discussion, since it is not
directly relevant to the release of Emacs 24.4.

Re: Emacs-24.4's release

[Eric S. Raymond]

David Reitter <david.reitter@gmail.com>:
> Will there be a mapping that aligns rev-ids from the old official
> git mirror to the new git repository?

I could construct one, but this is not a request that has come up
before.  It would require a significant amount of new work.

> I tried loading the Emacs repository into reposurgeon.  I ran out of
> time/disk space - can you comment on how large the temporary
> fast-export file is, and how long it takes to export it?

It's bloody huge and it takes forever.

My full conversion runs take about 10 hours on a dual-core 2.66Ghz
machine, and I bought a terabyte drive so I wouldn't run out of space
while doing them.

I should have more exact numbers for you in nine hours or so.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-24.4's release

[David Reitter]

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.

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.

I’d say, do not create this alignment table if it is a lot of work.  

> My full conversion runs take about 10 hours on a dual-core 2.66Ghz
> machine, and I bought a terabyte drive so I wouldn't run out of space
> while doing them.
> 
> I should have more exact numbers for you in nine hours or so.

OK, with that I could go find a machine.  However, I probably couldn’t do this every time I start reposurgeon.

Maybe I can figure out how to do this cutting operation manually with git.

Re: Emacs-24.4's release

[Eric S. Raymond]

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>

Re: Emacs-24.4's release

[David Reitter]

On Oct 14, 2014, at 6:49 PM, Eric S. Raymond <esr@thyrsus.com> 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

Re: Emacs-24.4's release

[Alan Mackenzie]

Hello, Glenn and Stefan.

On Mon, Oct 13, 2014 at 12:42:54PM -0400, Glenn Morris wrote:
> Stefan Monnier wrote:

> > Barring any major problem encountered til then, we intend to cut the
> > 24.4 release candidate this Friday, and (assuming nothing went wrong
> > with that candidate) make the release official the subsequent Monday.

> PS Just in case there was any doubt, this means:
> after the release candidate is made, do not commit ANYTHING to emacs-24
> without asking here first.

I think bug #18725 (Say "no" to "erase customizations?". .emacs gets
written.)  is a candidate for a major problem.  Basically, in certain
customize-... functions, .emacs gets saved despite the user explicitly
saying "no".  This is really bad, and I think it should be fixed for
emacs-24.  

I have proposed a patch to the code under the bug report.  May I apply
it?

> In fact I would really appreciate it if people do not commit anything to
> emacs-24 after 0000 UTC on Friday.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-24.4's release

[Glenn Morris]

Alan Mackenzie wrote:

> I think bug #18725 (Say "no" to "erase customizations?". .emacs gets
> written.)  is a candidate for a major problem.  Basically, in certain
> customize-... functions, .emacs gets saved despite the user explicitly
> saying "no".  This is really bad, and I think it should be fixed for
> emacs-24.  

I see it was already installed.
Why is it really bad?
It's not a new problem, is it?
It just saves the file the same as before, it doesn't change it, right?

Re: Emacs-24.4's release

[Michael Welsh Duggan]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote:
>
>> Barring any major problem encountered til then, we intend to cut the
>> 24.4 release candidate this Friday, and (assuming nothing went wrong
>> with that candidate) make the release official the subsequent Monday.
>
> PS Just in case there was any doubt, this means:
> after the release candidate is made, do not commit ANYTHING to emacs-24
> without asking here first.
>
> In fact I would really appreciate it if people do not commit anything to
> emacs-24 after 0000 UTC on Friday.

Please consider the following bug a major bug that needs to be fixed for
the new release:

Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749

Sorry for the late bug report, but I only recently managed to create an
example for this bug that could be replicated easily.  I would be very
sad if this bug (which I have encountered frequently as a heisenbug) is
not fixed for the new release, as it can make programming in C under
Emacs extraordinarily painful at times.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Emacs-24.4's release

[Glenn Morris]

Michael Welsh Duggan wrote:

> Please consider the following bug a major bug that needs to be fixed for
> the new release:
>
> Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749

Same issue in 24.1 and 24.3, and it's my impression that cc-mode has
repeatedly had such problems, so I'm not inclined to wait for this.

Re: Emacs-24.4's release

[Alan Mackenzie]

Hello again, Michael.

On Thu, Oct 16, 2014 at 05:26:55PM -0400, Michael Welsh Duggan wrote:
> Glenn Morris <rgm@gnu.org> writes:

> > Stefan Monnier wrote:

> >> Barring any major problem encountered til then, we intend to cut the
> >> 24.4 release candidate this Friday, and (assuming nothing went wrong
> >> with that candidate) make the release official the subsequent Monday.

> > PS Just in case there was any doubt, this means:
> > after the release candidate is made, do not commit ANYTHING to emacs-24
> > without asking here first.

> > In fact I would really appreciate it if people do not commit anything to
> > emacs-24 after 0000 UTC on Friday.

> Please consider the following bug a major bug that needs to be fixed for
> the new release:

> Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749

Ah.  One of _those_ bugs.  ;-(

> Sorry for the late bug report, but I only recently managed to create an
> example for this bug that could be replicated easily.  I would be very
> sad if this bug (which I have encountered frequently as a heisenbug) is
> not fixed for the new release, as it can make programming in C under
> Emacs extraordinarily painful at times.

With all the info you've provided, it should be straightforward to knock
this one down in at most a few hours.  I don't want to start on it now
(it being almost midnight in central Europe), but I'll get cracking on it
early tomorrow morning.

> -- 
> Michael Welsh Duggan
> (md5i@md5i.com)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-24.4's release

[Glenn Morris]

Glenn Morris wrote:

>> Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749
>
> Same issue in 24.1 and 24.3, and it's my impression that cc-mode has
> repeatedly had such problems, so I'm not inclined to wait for this.

PS but Stefan please say whether you agree/disagree...


PPS Past instances of this kind of thing:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9560
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11749
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16910

Re: Emacs-24.4's release

[Stefan Monnier]

>> Please consider the following bug a major bug that needs to be fixed for
>> the new release:
>> Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749
> Same issue in 24.1 and 24.3, and it's my impression that cc-mode has
> repeatedly had such problems, so I'm not inclined to wait for this.

Indeed, it's good to fix those bugs, but they're not urgent enough to
delay the release.  For all I know, the fix could be non-trivial and
hence inappropriate for 24.4.

So, Alan, if you find the fix early tomorrow morning and it's obviously
safe, feel free to install it in emacs-24, but otherwise please wait to
install it after the release.


        Stefan

Re: Emacs-24.4's release

[Glenn Morris]

Stefan Monnier wrote:

> So, Alan, if you find the fix early tomorrow morning and it's obviously
> safe, feel free to install it in emacs-24,

That means I have to wait to make the release candidate.

Re: Emacs-24.4's release

[Glenn Morris]

I've set the version number in preparation, but this is neither the
release nor (yet) a release candidate.

Re: Emacs-24.4's release

[Alan Mackenzie]

Hello, Stefan and Glenn.

On Thu, Oct 16, 2014 at 08:21:54PM -0400, Stefan Monnier wrote:
> >> Please consider the following bug a major bug that needs to be fixed for
> >> the new release:
> >> Bug#18749: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18749
> > Same issue in 24.1 and 24.3, and it's my impression that cc-mode has
> > repeatedly had such problems, so I'm not inclined to wait for this.

> Indeed, it's good to fix those bugs, but they're not urgent enough to
> delay the release.  For all I know, the fix could be non-trivial and
> hence inappropriate for 24.4.

The fix (see patch in bug report thread for #18749) is trivial enough,
i.e. it's straightforward and easy to see that it's harmless.

> So, Alan, if you find the fix early tomorrow morning and it's obviously
> safe, feel free to install it in emacs-24, but otherwise please wait to
> install it after the release.

I'm going to commit it to the trunk today.

The bug is a serious one, in that once the bug syndrome hits a C file
(which will happen if an "interesting" place in the file is 500, 512, or
1000 non-literal characters after a "#"), it causes chaos.  This is
going to happen not frequently, but also not all that rarely.  Very few
people have Michael Welsh Duggan's tenacity and bug reporting skills.

I think, on balance, the fix is important enough to have gone into 24.4,
but the judgement is a fine one.  Perhaps it is not important enough to
justify rebuilding the 24.4 release.

On the other hand, should 24.4 need to be rebuilt for some other reason,
I ask that the fix to #18749 be incorporated into the final build.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-24.4's release

[Glenn Morris]

Alan Mackenzie wrote:

> On the other hand, should 24.4 need to be rebuilt for some other reason,
> I ask that the fix to #18749 be incorporated into the final build.

I'll try to remember that.
In the meantime, I ask people to test this out.
(If possible, in emacs-24, but trunk is probably ok too.)

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

Re: Emacs-24.4's release

[Jan D.]

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

Re: Emacs-24.4's release

[David Reitter]

Hi Jan,

I’m not sure why you’re asking, so there are two answers:

As for the repository, we don’t actually have a branch in the GNU Emacs repository and don’t need one - and if that’s what you’re asking - I’m not planning for this to happen.

But of course I merge regularly from the Emacs branches, and the big rebase that Eric did prevents me from continuing unless we transplant or discard 10 years of Aquamacs history somehow.

As for using code from Aquamacs and copyright:
 
Aquamacs is at liberty to incorporate any GPL’ed and license-compatible code into its codebase.  Contributors retain their copyright and license it under the GPL as appropriate.  They have not signed GNU papers.

I myself have signed papers.  If you want to use any of my code, that’s fine by me of course.  In fact, I would like to see more of that.

- David


> On Feb 5, 2015, at 9:56 AM, Jan D. <jan.h.d@swipnet.se> wrote:
> 
> 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>
>> 
> 

Re: Emacs-24.4's release

[Jan D.]

David Reitter skrev den 2015-02-05 16:06:
> Hi Jan,
>
> I’m not sure why you’re asking, so there are two answers:
>
> As for the repository, we don’t actually have a branch in the GNU
> Emacs repository and don’t need one - and if that’s what you’re
> asking - I’m not planning for this to happen.

Ok, I thought you asked for that, as this message is on emacs-devel.
If that is not the goal, then it is between you and Esr.

	Jan D.

Re: Emacs-24.4's release

[David Reitter]

On Feb 5, 2015, at 10:33 AM, Jan D. <jan.h.d@swipnet.se> wrote:
> Ok, I thought you asked for that, as this message is on emacs-devel.
> If that is not the goal, then it is between you and Esr.

Yes, I know.  I was thinking my messages were getting spam-filtered at Esr’s end, so I posted to -devel as well.  

I don’t mind more exchange between Aquamacs and Emacs, here or on a code basis.  Now that we’re using the same version control system, this will be easier.  Unfortunately, I don’t have as much time for this as I used to.

- D