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

[Philip Kaludercic <philipk@posteo.net>]

Suhail Singh <suhailsingh247@gmail.com> writes:

> 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).

One concern I have would be that an entire revision string can get very
cluttered, and is usually not interesting (as I don't use third-party
archives, I don't have duplicates of the kind that you describe).  I
wonder if indicating a "commit mismatch" for remote packages might be
interesting (we explicitly don't want this for local packages,
e.g. packages installed via package-vc).

Could you perhaps elaborate on why you consider this to be a bug?

>> 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.

True, but there are many things that could be made more convenient that
only interest few people.  I am trying to understand why this is
something that would interest everyone.

>> There is the possibility of using a symbolic name if available.
>
> Could you please give an example?

What I had in mind was using `vc-git-symbolic-commit'.  So in the case
of Git: If the commit
is following the "master" branch, then it would print "master" instead
a commit hash, likewise if the package is checked out on some tag, it
could display that.

>>> 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'.

From what I see, that would only give us "the time of the next line of
annotation at or after point, as a floating point fractional number
of days.", and not something we can cleanly use to get an exact date.  I
mean you could try to multiply it with (* 60 60 24) to get the value
that was probably passed to `vc-annotate-convert-time', but that feels
unreliable to me.  But I too might be mistaken.

>> 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)?

In the case of Git it is just a commit hash, like the ones you gave above?

-- 
	Philip Kaludercic on siskin