|
From: | Dmitry Gutov |
Subject: | Re: ELPA commit freeze |
Date: | Wed, 21 Aug 2013 02:22:04 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 |
On 20.08.2013 17:45, Stefan Monnier wrote:
So we could check out the version before externals were introduces, erase all their respective directories, then apply all commits made to the "administrative" part of the tree, and then add the subtrees properly. Some cleanup commits would have to be re-applied, but there's not a lot of them.We could try to do that. I'm far form convinced it's worth the trouble.
Yep, I've tried that, and some of the subtree merges were done quite a while ago, e.g. coffee-mode. Maybe it's indeed not worth the trouble.
If it's too late, I suppose we can live with that, but this way we a) give up an easy way to sync back, b) accept that we'll see each non-upstream commit in externally maintained packages's histories twice: once for when it's made, second after it's cherry-picked, committed to upstream and then merged back into elpa.Not that "git subtree push" also duplicates the commits. It just automates the process. So, it's only a) that's lost.
Yes, I should've checked. So, if git-subtree does not include any additional conflict-resolving functionality, I guess sending commits from elpa to relevant upstreams by email should be close enough.
I guess the main drawback left is if anyone else looks at the description of how elpa is organized, thinks "git subtree!", and spends time trying to make it work properly.
That aside, could you look at the following emails? I sent them via Yandex's SMTP server accidentally and, as usual, they were bounced back from perlin.IRO.UMontreal.CA by timeout.
http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00521.html http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00522.html
[Prev in Thread] | Current Thread | [Next in Thread] |