From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Git version of ELPA Date: Mon, 12 Aug 2013 21:42:08 -0400 Message-ID: References: <8738qs5qrg.fsf@igel.home> <87mwoz4w4f.fsf@igel.home> <877gfrrida.fsf@yandex.ru> <52087DDD.1020100@yandex.ru> <52090C0F.4020508@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1376358147 27690 80.91.229.3 (13 Aug 2013 01:42:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Aug 2013 01:42:27 +0000 (UTC) Cc: Andreas Schwab , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 13 03:42:27 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 1V93cv-0004L1-Mi for ged-emacs-devel@m.gmane.org; Tue, 13 Aug 2013 03:42:26 +0200 Original-Received: from localhost ([::1]:58581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V93cv-0004Qs-7v for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2013 21:42:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V93cl-0004Pe-Kn for emacs-devel@gnu.org; Mon, 12 Aug 2013 21:42:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V93cf-0007GA-NA for emacs-devel@gnu.org; Mon, 12 Aug 2013 21:42:15 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:65047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V93cf-0007G4-HU for emacs-devel@gnu.org; Mon, 12 Aug 2013 21:42:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJCyHcgbBLY0ag3ADlymNUYFegxOBSw X-IPAS-Result: Av4EABK/CFFLd/Nq/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJCyHcgbBLY0ag3ADlymNUYFegxOBSw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="21581319" Original-Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Aug 2013 21:42:01 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1535D62E98; Mon, 12 Aug 2013 21:42:08 -0400 (EDT) In-Reply-To: <52090C0F.4020508@yandex.ru> (Dmitry Gutov's message of "Mon, 12 Aug 2013 19:23:43 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162640 Archived-At: > 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: I'm mostly concerned about keeping the `elpa' code up-to-date, i.e. merging from external repositories into elpa, not the other way around. Git's subtrees handle this well. To merge elpa changes back into the external repository, the best option is to cherry-pick patches. I don't think there's any VCS that can handle this side of the sync semi-automatically, because I don't know of any VCS that handles two-way syncs (except maybe for the special case where both sides are meant to be exact mirrors, but even those can be tricky). So subtrees don't make any difference in this respect, AFAIK. >> 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. With subtrees, I can do bzr merge --subtree and it will work whatever has changed since the last merge of that branch. But that was already true to some extent with Bzr. The difference is that this now works without "bzr join" and its bugs (and also that most external branches are using Git, so we also avoid the bugs of bzr-git). I.e. instead of "bzr join" which can only add a new tree, I can do bzr merge --subtree for a branch that I've never merged before: for lack of a common ancestor it can't know what's new and what isn't, but it does the sane thing: a 2-way "merge". >> The `elpa' code will always tend to include local changes. Less is >> better, but they're a fact of life. > Inside package directories? Yes. > How necessary is that? Indispensible. > If you mean bugfixes touching several packages at once, Not only. The difference can have to do with packaging, or with non-copyright-assigned code, ... In any case it's the responsibility of the package's maintainer to feed elpa changes back to the external branch, if any. > they should be prime candidates for splitting and pushing upstream (I > think git subtree supports that, not 100% sure). Sure. > On the subject of extra files, more specifically: > 1) Can we do without README and -pkg.el files? The -pkg.el is the one that holds the metadata, so it's pretty important. We could get by without it if /.el contains the corresponding info in the usual single-file format, but currently the presence of -pkg.el is used to indicate that this is a multifile package rather than a singlefile package, so we'd need that info elsewhere. Mostly same story for README, except that it's a bit easier (the code I have might already fallback to reading the Commentary section of /.el if the README file is missing). > 2) Can we handle having README.md (and probably other formats), Yes. Patches welcome (tho you might like to wait before the new Git repository is in place, since the code is being rewritten as we speak). > .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. Currently, you can have extra (ignored) files only for singlefile packages. Multifile packages will package up whatever is present. But it should be easy to add some way to list files that should be skipped. IOW, same as above "patch is welcome, tho you might like to wait a bit". > 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). That's partly the way it's heading. > 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? Hmm... I didn't think about that. Kinda stupid, eh? It's probably a bit late, tho (I have most of the old code adjusted already). In any case, for enhancements, it's probably a good idea to look there. > If maybe, do we care about copyright assignments for its code? We would, of course. > My intention here was to illustrate the difference between the file trees, > not between their contents. You'd have to ask Yidong, but I have the impression that yasnippet was not installed in GNU ELPA in a straightforward way to start with (usually I try to limit changes to copyright-fix up and things like that); but sadly I can't remember details about that. Stefan