From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Git version of ELPA Date: Mon, 12 Aug 2013 19:23:43 +0300 Message-ID: <52090C0F.4020508@yandex.ru> References: <8738qs5qrg.fsf@igel.home> <87mwoz4w4f.fsf@igel.home> <877gfrrida.fsf@yandex.ru> <52087DDD.1020100@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376324642 32143 80.91.229.3 (12 Aug 2013 16:24:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Aug 2013 16:24:02 +0000 (UTC) Cc: Andreas Schwab , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 12 18:24:05 2013 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 1V8uua-00054j-As for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2013 18:24:04 +0200 Original-Received: from localhost ([::1]:36909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8uuZ-0000wX-LN for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2013 12:24:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8uuS-0000uU-Iv for emacs-devel@gnu.org; Mon, 12 Aug 2013 12:24:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8uuN-00008q-VS for emacs-devel@gnu.org; Mon, 12 Aug 2013 12:23:56 -0400 Original-Received: from forward5h.mail.yandex.net ([2a02:6b8:0:f05::5]:58677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8uuN-00007s-Hl for emacs-devel@gnu.org; Mon, 12 Aug 2013 12:23:51 -0400 Original-Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 23407D01928; Mon, 12 Aug 2013 20:23:49 +0400 (MSK) Original-Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 5F5F31B4151C; Mon, 12 Aug 2013 20:23:48 +0400 (MSK) Original-Received: from 93-245-142.netrun.cytanet.com.cy (93-245-142.netrun.cytanet.com.cy [93.109.245.142]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dohyIUySAW-NljW6gXJ; Mon, 12 Aug 2013 20:23:47 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1376324627; bh=208upxUFLQ1c552RRnlAmXJEw8QzdS4TUEsJVU46bBU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iZgpdtLxob1IRDGMSJVQi0KHoEDIDBtYSV+ch/ybzqDd9ciTCLjdcy2JEl4VC1psu IHvidVBX3tExz1yGuXebet+ZGA1r485bS7Ss7R9ic9AR2SSC9Oo90Gsnkjx8Tol8SY N1ZNcTQy4dXqxgWWYnsOhaXHQpBgowW+n64X+Bjg= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a02:6b8:0:f05::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:162626 Archived-At: On 12.08.2013 18:24, Stefan Monnier wrote: >> So, you've tried merging commits from upstream that include files not >> present in ELPA? And splitting commits from ELPA to push them to upstream >> repositories? And both work fine? > > Haven't tested any of them, since neither of them is supported by the > current Bazaar setup: it can't be worse than what we have in this respect. I'm making this emphasis because git subtree has been mentioned several times, and its apparent advantages include being able to merge in both directions. If you don't have external repos' histories, apparently splitting commits and pushing them back won't work: http://stackoverflow.com/questions/5760331/git-subtree-is-not-retaining-history-so-i-cannot-push-subtree-changes-how-can-i >>> Of course, if there's a better Git tree available, I'll happily switch >>> to that one. >> A little while back Jorgen wrote a recipe how to do that: >> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00235.html >> I've yet to wrap my head around this git subtree business properly, but if >> it helps, I can try to follow it myself, and publish the result. > > That would be nice. I did not insist on it, because my tests showed > that you can "subtree merge" an external branch after-the-fact: with > Bazaar this resulted in serious problems, whereas with Git this is > handled sanely (not as well as having the external branch merged > right from the start, of course, but good enough). With Bazaar, I always just copied the most recent versions of files in a package, more or less manually, then marked them in `vc-dir' buffer and committed the result as the new revision. I don't think that doing only a little better than that is good enough. >> It raises a few questions, though. Up until now, the elpa branch has been >> receiving its contents in preprocessed form: >> 1) Some files and directories removed. >> 2) -pkg.el files pre-generated and included. > > The `elpa' code will always tend to include local changes. Less is > better, but they're a fact of life. Inside package directories? How necessary is that? If you mean bugfixes touching several packages at once, they should be prime candidates for splitting and pushing upstream (I think git subtree supports that, not 100% sure). On the subject of extra files, more specifically: 1) Can we do without README and -pkg.el files? 2) Can we handle having README.md (and probably other formats), .travis.yml, Makefile, extra dirs and .el files not meant for end users? Like `doc', `extras', `yasnippet-debug.el' and `yasnippet-tests.el' in the yasnippet repository on GitHub. Probably not, but Melpa does this okay. Aside from not having to pull from hundreds of external repositories, I think ELPA should work the same way (but also retain and use the Version header values). If implementing it is going to be a lot of work, are we willing to take package-build.el from the Melpa project and adapt it, or reuse some of its pieces? If maybe, do we care about copyright assignments for its code? >> For example, just compare >> http://repo.or.cz/w/emacs.git/tree/dbb5d60608ae6b99910b0c374f82b63fde526abf:/packages/yasnippet >> and >> https://github.com/capitaomorte/yasnippet/ > > yasnippet is a problem, indeed. Someone needs to sync up the two trees > (and take responsibility to keep them in sync in the future). We can try to ping Joao, but that's a separate issue. My intention here was to illustrate the difference between the file trees, not between their contents.