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: Thu, 26 Nov 2015 09:34:23 -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 1448548496 7103 80.91.229.3 (26 Nov 2015 14:34:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 14:34:56 +0000 (UTC) Cc: "=?utf-8?Q?Fabi=C3=A1n?= E. 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 15:34:43 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 1a1xdB-0001lc-GU for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 15:34:41 +0100 Original-Received: from localhost ([::1]:51563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1xdD-0004D9-I4 for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 09:34:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1xcz-0004Cs-JL for emacs-devel@gnu.org; Thu, 26 Nov 2015 09:34:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1xcv-0006TF-F8 for emacs-devel@gnu.org; Thu, 26 Nov 2015 09:34:29 -0500 Original-Received: from mail-ig0-x233.google.com ([2607:f8b0:4001:c05::233]:35262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1xcv-0006SH-5z for emacs-devel@gnu.org; Thu, 26 Nov 2015 09:34:25 -0500 Original-Received: by igl9 with SMTP id 9so11965785igl.0 for ; Thu, 26 Nov 2015 06:34:24 -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=koEg2E5a+J0Daqr4EKZIiOgjRBDVvIjOd4RX9jFTrPk=; b=pr15+Kv7g1SEZcK8QeIEtW9lXcrhdZzwo/onq3PSLdIpyqKmA/fLWeN4ZNDJF72ZPJ CJ36hSsz48GxUwX+PCArVofP4p86B3iBSHZKxHuOpQKo6POGU3a8HTlrkOjsqU6dp4wq FesV0KL/mvqesT2qa1bIBJmKfCUif9TP4//QzKD/td/Cw3gsDTsRGJi/Qjdh1IxEBPtD rvT0gFOasPNh4yGxkJOkLBzFonDP0Gr9pGwvo53R/p/tiETMtlPULILD8ae+3M64jETr Ps7Q/I1M10SljS1DeDik2VShaMo3Yg1pOdzxtEjY5FpEXxIfNF51WcPECPO4NUVAvCIB 8+ig== 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=koEg2E5a+J0Daqr4EKZIiOgjRBDVvIjOd4RX9jFTrPk=; b=GoEEdNyG3SbgJQUt2w0pa1NptVgPCq45yUuwwAbV5ZC+fyY0feZG2KStlKkVvUvTzA +ydVfn87/HHgIKS2auf61rh6TYDGNuR/lduSnehXTPtpGimCEuh1HLeEW7tr85qAIUm1 mZrQhg+f0orjri40pZOBiDlg1diAEeMvX7eirEBfR8ERW3I+Pc8QpoY04R/daLQpNd8b nfiVFZP7OkruKsAw3MsY27CvH/fCVAQLU7YkXh9ky3R1Uk4yibsw9xx81fRMnT+7zbkV hDGuWtLL5roCd7ik/IBdpriOvwc1cI7gcXDCXYMcUa1hKOCBOO5G0A+LRwt2F2el0X0n 3+yw== X-Gm-Message-State: ALoCoQnygNaE0FeYhmoy7xwGenySeCgRHgyCG12TGg7T526MI6moNP9SjelYFpRVMO3ZLDWvbfAK X-Received: by 10.50.131.129 with SMTP id om1mr3189172igb.83.1448548464456; Thu, 26 Nov 2015 06:34:24 -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 s95sm10685802ioe.16.2015.11.26.06.34.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Nov 2015 06:34:23 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Wed, 25 Nov 2015 22:55:09 -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:c05::233 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:195283 Archived-At: 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. > > Yes, that's the important case. BTW, I found myself being more focused on the "in place archive" use case. That's how I ended up invoking the process-archive target directly which indirectly deleted .git (this is the one my patch now prevents). I think the default "make" target should also generate the archive directory so that one can always test "what will be published" with: rm -rf test-home && mkdir test-home && HOME=`pwd`/test-home $TARGET -Q \ --eval \ "(setq package-archives '((\"local\" . \".../elpa/archive/packages\")))" Then one can test dependency resolution, byte-compilation and compatibility on the "target Emacs" -- I test Emacs 24.1 through 24.5 and master. Testing just against the default emacs on PATH (what "make" does right now) is OK for development, but GNU ELPA should encourage backward and forward compatibility. >> There are lots of points where directory deletion happens in GNUmakefile >> and archive-contents.el, during both "make externals" and "make >> archive". > > Deletion in "make archive" is not a problem, AFAICT. > >> 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: > > Exactly. > >> ;; 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. > > Yes, this is the problematic case. This case is the one that intends to > handle the situation where we removed a :core package from > externals-list. > > Presumably the call-process check should make sure this directory is not > under Git control at all, so no amount of "git status" will help. > > So here, instead of delete-directory we should use a new function which > is a lot more careful, so it only deletes data which it has earlier > created for a :core package. If the :core packages are handled via > symlinks, then this can be done by checking that the directory only > contains symlinks (or subdirs with the same property). Of course there > are other ways, such as keeping track somewhere of the files we've > installed as :core, and then check this info before we delete files. OK, I'll work on this. >> I didn't closely follow the discussions while this was being designed. >> Was there some reason to avoid git submodules? > > "git submodules" could make sense (and I did consider them) for > the :external packages, but these aren't affected by this code (since > the call-process should indicate that they are under Git). > >> It seems possible to replace "make externals" with submodules that >> track "remote" externals/ branches of elpa.git itself, with git >= >> 1.8.2. > > IIRC the issue with git submodules is that they have to refer to > a particular revision rather than to a branch, so additionally to > committing new code on the external branch, you'd then have to go and > commit a change to master that updates the submodule reference to point > to the new revision at the head of the external branch. That was true at one point but it looks like git 1.8.2 introduced the notion of "remote-tracking branch submodules". Maybe I'll experiment with how that could work for elpa.git. Thomas