Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>                 We're not there yet, but the above adds info which we
>>> can (and do in `elpa-admin.el`) extract from the VCS, so it's going
>>> "backward".  IOW, it's making things worse rather than better.
>>
>> You mean the addition of :release-rev, right?
>
> Yes.
>
>> Yes, it could be extracted from the VCS, but finding a generic system
>> is tricky as you have mentioned.  How about a new VC method
>> `last-change' that takes a region and returns the last revision that
>> affected it.  Any backend that supports `annotate' ought to be able to
>> determine it, right?
>
> Fine by me.  As mentioned earlier, there's a good chance that if you use
> a different VCS than Git, this method will sometimes end up selecting
> a different commit than `elpa-admin.el`, but if we insist on supporting
> a local VCS different from the one used by `elpa-admin.el`, then we
> probably have to live with that.

I guess so.  Here is a possible patch that should behave close enough to
elpa-admin.el using "blame" (an obvious exception is the missing handler
for the new :merge property, but I have been wondering if it might also
be fair to always add "--first-parent" for Git).

The default handler just wraps vc-annotate, so it is a bit more fragile.

0001-Extract-last-source-package-release-from-local-VCS-d.patch
Description: Text Data

Invoking `package-vc-install' with a prefix argument will now check out
the specific commit that bumps the version tag.  At least for git, the
slight problem here is that this means the head is in a detached state,
not connected to any specific branch.  I don't know if there is any
elegant solution to this problem, or if it should even be "solved".