Re: feature/package-vc has been merged

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: monnier@iro.umontreal.ca,  rms@gnu.org,  emacs-devel@gnu.org
>> Date: Sun, 06 Nov 2022 16:42:37 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> That I did not know.  The issue with copying is that you loose vc
>> >> information.
>> >
>> > Why do they need VC information inside ~/.emacs.d/ ?
>> 
>> While not strictly necessary, a big part of the motivation of package-vc
>> is the ability to easily work on packages that are usable as regular
>> packages.  If I M-x find-function into a ~/.emacs.d/elpa/ and make a few
>> changes, having to distinguish between packages between packages with
>> :lisp-dir attributes and those without seems unnatural.
>
> Sorry, I don't follow: what does find-function etc. have to do with
> having the VCS data inside ~/.emacs.d/elpa/?  By "vc information" you
> meant what Git stores in the .git directory, yes?  I'm asking why it's
> important to have that in ~/.emacs.d/elpa/.
>
> Or maybe I don't understand what you mean by "work on packages that
> are usable as regular packages"?

Let's say I notice a something I would want to change/add/fix in a
package I am using.  find-function is just one way I would query Emacs
to open up the source, then make a few changes.  If I decide that these
are worth up-streaming, it is nice to just commit them right away and
call `package-vc-prepare-patch' to send the maintainer an email.  That
last part won't work if the files were copied, because in that case I'll
have to copy my changes back to the actual repository, create a commit
in there, then send out the patch, which (right now) couldn't make
immediate use of the package metadata, so you'd have to fall back to
`vc-prepare-patch' and find out who the maintainer is manually.

All of this would only apply to packages with external `:lisp-dir's,
which doesn't immediately interest a user/developer.  Having to keep
this in mind would pointlessly expose an internal detail of package-vc
that I'd like to avoid.