Re: Reconsider defaults for use-package-vc-prefer-newest

[Suhail Singh <suhailsingh247@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

>> Would it be possible to reflect the commit corresponding to the version
>> in the "Other versions:" field in the output of M-x describe-package ?
>
> Why under "Other version:" (which links to other packages).

For a package that is available under both MELPA Stable and NonGNU ELPA
one can encounter the situation where the versions look the same, but
instead point to different commits.  They don't necessarily have to
point to different commits, and in fact when they do I would consider it
a bug.  However, as of today, a user only becomes aware of this if they
follow the links in the "Other version" and then contrast the "Commit"
information in the subsequent package's description with the one from
the prior page.

An example of a package where this was observed in the wild (probably
not the only case) was julia-mode.  The 0.4 version of that package on
NonGNU corresponds to commit 6408b96c1c97e41bc2af060d661afee4f7b22e89
whereas the version 0.4 on MELPA Stable corresponds to commit
8bfc709716a257521cb386f20b8932e83db930a9 .

Since the information is available via M-x button-describe on the links
to the other packages, hopefully it could be made visible (perhaps via
some customization).

> IIRC the commit of a VC package should appear under the commit header.

That necessitates additional clicks.  If those clicks or button pushes
could be avoided it would improve user convenience.

> There is the possibility of using a symbolic name if available.

Could you please give an example?

>> Additionally, if it were possible to reflect the commit date as well,
>> that would be helpful as well.
>
> I don't think there is a nice vc-generic way to extract the date of a
> commit, at least without extending the vc interface any further.  I
> might be mistaken though.

I may be mistaken, but my understanding was that if `annotate-command'
is defined for a backend then this may be possible via `annotate-time'.

> The other issues is that if you only have the revision string from the
> ELPA server, without any checkout, it isn't easy/cheap to determine the
> date even if you just wanted to support Git.

Ah.  That is, indeed, a problem.  Out of curiosity, what is an example
of such a revision string (say, for the julia-mode package from NonGNU
ELPA)?

-- 
Suhail