From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.devel Subject: Re: [elpa] master 872014e: Prevent accidental deletion of .git Date: Wed, 25 Nov 2015 22:08:41 -0500 Message-ID: References: <20151109013124.17711.29422@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448507346 11681 80.91.229.3 (26 Nov 2015 03:09:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 03:09:06 +0000 (UTC) Cc: =?utf-8?Q?Fabi=C3=A1n_E=2E_Gallina?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 26 04:08:51 2015 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 1a1mvR-0000AS-TT for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 04:08:50 +0100 Original-Received: from localhost ([::1]:48813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1mvT-0002R4-F8 for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 22:08:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1mvP-0002Qh-Ef for emacs-devel@gnu.org; Wed, 25 Nov 2015 22:08:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1mvM-0002CK-7X for emacs-devel@gnu.org; Wed, 25 Nov 2015 22:08:47 -0500 Original-Received: from mail-io0-x22e.google.com ([2607:f8b0:4001:c06::22e]:35720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1mvM-0002C2-1m for emacs-devel@gnu.org; Wed, 25 Nov 2015 22:08:44 -0500 Original-Received: by ioc74 with SMTP id 74so72422535ioc.2 for ; Wed, 25 Nov 2015 19:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=2onZlskDAMLIleQa1wRNrO6fhV1rZessbAxsR079WMM=; b=XsJsMWCE9IHL+mkDKa0YDKI2R2EG02KpZqZXQH9Q9rYarr5UHpd3L9h9aoy7A1OktD W7Rc+xRbKJfvP2ehj8CBeuqSkBtkksLiOPd8FHBkAZ5rtCT3b8v1Int1t1BsNn9DEDsj Js1SMW/qYJq33YKUhEWeeC73pZQDi/ukBZejwiWMHgC2fTMC9KDAqcr7knMq4BJ8oJ3s 44m6Jjlo14NH3IZAUBcEGHJR98eTifE7y8D66K4LBD/9OX9NnTaqRIRLZDRMoX1RvS37 vGvqiS43naHF61611i81wl42J+dDIiyVp2PEpYa37iNjv4u6K1i7/JTH015JqdxpSlBX +O5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=2onZlskDAMLIleQa1wRNrO6fhV1rZessbAxsR079WMM=; b=KMu8cuohx6SnKEyI4dyHQbKqbUkvUfqaC67/fbr5yFlfyrNvFA8OmEuBi2AicixgcZ YUxr6UVnKwNqNYb0eVCPxpYgWq7WnZUVPkonDejhufE0NvCOOFkTfklRvbverYMmcEzx 8yLyJkC2XWPgA1juoKb9r/MmbXNTdWCpT+ruoIJk7G3L/ag6eTHHW4i6t8+hEGOPv42J ebMeXIfKzO615Tjg2wRhy5+q1uzWNzKLItI/pk/3CK+LerHznhG/tsBtX9aldHEXFqdh vJhsdFirTzEHOX2WaZPXoA5yJuZbzMnqi7KpX9eBVSjaiqSLqgN1m0R9AVTp+1ZK2umO enhA== X-Gm-Message-State: ALoCoQmXbPXgp8xzFoS6NVDX8RJLExNH/uvHgQ2peZMxUPE1WEnmLMGMZ3clHXBfOUvFyJFI1LIF X-Received: by 10.107.34.7 with SMTP id i7mr39546697ioi.32.1448507323439; Wed, 25 Nov 2015 19:08:43 -0800 (PST) Original-Received: from hp-dv5t (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id 14sm9913889ior.25.2015.11.25.19.08.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2015 19:08:42 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Wed, 18 Nov 2015 10:10:26 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c06::22e 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:195270 Archived-At: Hi Stefan, Stefan Monnier writes: [...] > We'd also want to try and fix the directory-deletion code accordingly, > so it's less trigger happy. I've been looking at how to do this, but I'm not sure exactly what you're after. The following is from the perspective of "in place" development. For the deployment case, deletions etc. make perfect sense since those scripts are operating on committed code. There are lots of points where directory deletion happens in GNUmakefile and archive-contents.el, during both "make externals" and "make archive". For "make archive", directory deletions all happen under "archive-tmp" -- this is now enforced by my change to use cd ... && ... in the make recipe. The specific directory deletion that bit me is in batch-make-achive: (progn ;; Negative version: don't publish this package yet! (message "Package %s not released yet!" dir) (delete-directory dir 'recursive)) To avoid `delete-directory' calls entirely, we could create archive-tmp additively by only copying over releasable directories. But then the first step will still be "rm -rf archive-tmp" in the Makefile. Do you think it's worth the effort to rewrite this to do selective copying, rather than just ensuring directory deletions only happen in archive-tmp? As for "make externals", I don't really like the concept of it, because it mixes the build process with source configuration management. For example, this directory deletion could remove in-progress work from my source directory, under elpa/packages: ;; Check if `dir' is under version control. ((not (zerop (call-process "git" nil nil nil "ls-files" "--error-unmatch" dir))) (message "Deleted untracked package %s" dir) (delete-directory dir 'recursive t)) I would never expect that when invoking make. I would rather "git status" tell me that I have untracked changes. I didn't closely follow the discussions while this was being designed. Was there some reason to avoid git submodules? It seems possible to replace "make externals" with submodules that track "remote" externals/ branches of elpa.git itself, with git >= 1.8.2. Then pure git operations could be used to e.g. ensure a clean working tree, instead of directory deletion Elisp. Thomas