Re: [elpa] master 872014e: Prevent accidental deletion of .git

[Thomas Fitzsimmons]

Hi Stefan,

Stefan Monnier <address@hidden> 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