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

[Suhail Singh <suhailsingh247@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

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

Depending on the logic of "commit mismatch" detection, that may be
sufficient.  Could you describe what you had in mind?

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

To be clear I meant that it's a bug in the remote package.
Specifically, in the case of julia-mode, it was a bug for it to have
introduced the 0.4 package header in a commit that was different from
the one that was tagged as 0.4.

I don't consider this to be a bug in package.el.  However, if package.el
had made it obvious that the 0.4 version from melpa-stable isn't the
same as the 0.4 version from nongnu, it would have saved me some
headache.

For my part, I know better than to take version numbers at face value
now, especially when they are from different archives.

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

I don't believe this would interest _everyone_.  I also don't believe
that that's the necessary bar for a feature.  One might argue that this
is too niche a feature.  I don't believe so, but I also am not sure if
my opinion on the matter has any significance.

The people to whom this would be of interest would be users who have
melpa-stable enabled and who use some packages that are available both
on melpa-stable and either nongnu or gnu.

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

At least for the scenario I am considering, symbolic names would not be
very useful.  Commits are useful because they are unique (more or less).

-- 
Suhail