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: Wed, 14 Aug 2013 23:46:10 +0300 Message-ID: <520BEC92.401@yandex.ru> References: <8738qs5qrg.fsf@igel.home> <87mwoz4w4f.fsf@igel.home> <877gfrrida.fsf@yandex.ru> <52087DDD.1020100@yandex.ru> <52090C0F.4020508@yandex.ru> <520B4B29.8030201@yandex.ru> <520BB4FA.4080903@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376513188 1219 80.91.229.3 (14 Aug 2013 20:46:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2013 20:46:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 14 22:46:31 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 1V9hxf-0003N0-1W for ged-emacs-devel@m.gmane.org; Wed, 14 Aug 2013 22:46:31 +0200 Original-Received: from localhost ([::1]:50020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9hxe-0000v2-LF for ged-emacs-devel@m.gmane.org; Wed, 14 Aug 2013 16:46:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9hxW-0000uj-Eg for emacs-devel@gnu.org; Wed, 14 Aug 2013 16:46:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9hxR-0008AZ-1M for emacs-devel@gnu.org; Wed, 14 Aug 2013 16:46:22 -0400 Original-Received: from forward2h.mail.yandex.net ([84.201.187.147]:41379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9hxQ-0008AL-Gp for emacs-devel@gnu.org; Wed, 14 Aug 2013 16:46:16 -0400 Original-Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 4DF3C700E17; Thu, 15 Aug 2013 00:46:14 +0400 (MSK) Original-Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id F38EE1340277; Thu, 15 Aug 2013 00:46:13 +0400 (MSK) Original-Received: from 62-107-247.netrun.cytanet.com.cy (62-107-247.netrun.cytanet.com.cy [62.228.107.247]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id wTvFk1gUPD-kCFuEtFR; Thu, 15 Aug 2013 00:46:13 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1376513173; bh=Pdg+ijVAIH22ILLIVG4HFxcdx5Rdxymzv1m+NK5Uh9k=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=boXfTUGHOSNuUmzR61Bl+cblgpwpQcArU5tkyPOAenWhmABTyzuDKsMPgKOykGB8O lUs8D4BpDDCRwZ5fO33SiuI8X5oyt5cmXvM9sPH+HZLENnYUOBHXVwYlv8bdHtExsq V1lByS61MTBkkXwj3Cyw57j1lye4uWXUEBgj+dlw= Authentication-Results: smtp1h.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: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.187.147 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:162740 Archived-At: On 14.08.2013 22:02, Stefan Monnier wrote: >>>> 2) If packages/js2-mode and git@github.com:mooz/js2-mode.git differ >>>> in files they contain, I imagine we'll have more errors or conflicts >>>> to deal with. >>> Yes and no: the "push" would simply force the github version to have >>> the same content as the elpa version. >> The push just after the removal commit would end up fine. > > No, by definition "push" gives you an exact copy at the other end. Yes, sorry. You're right, of course. As long as you've resolved all the conflicts during the previous merge, and the remote head is a proper ancestor of the local head, the push will succeed. Which, in the described situation, is arguably worse than failure. >>> A simple solution is to not remove those files from the `elpa' branch. >>> I.e. consider it as a "local change". It might lead to spurious >>> conflicts when merging, tho. >> Not sure I understand. I didn't suggest removing them. >> What changes, and "local" to what? > > Changes, as in "file removal", "file renaming", ... > Local to the `elpa' version. Ah, ok. I guess the "not" in "to not remove" above was a typo. >> Exclusions are fine by me, too. So, file name ".elpaignore", syntax similar >> to ".gitignore" (one glob per line)? > > Syntax: whatever "tar" accepts. Sounds good. Speaking of README file formats, maybe your current solution is good enough. The Melpa guys have intentionally settled on the same approach (use the Commentary from .el): https://github.com/milkypostman/melpa/issues/522 https://github.com/milkypostman/melpa/pull/366 The idea is that README.md/org/etc in the root of the directory serves as an introduction, and it usually contains a section "how to install". The package description buffer, on the other hand, would be most useful if it has a short description of what the package is about and how to use it *once it's installed*. I'm not sure if I fully agree with that reasoning, but doing readme generation the same way across package repositories would be good.