Suhail Singh writes: > Philip Kaludercic writes: > >>>> In your case/the case of julia-mode, something like >>>> >>>> Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH). >>>> >>>> with a help annotation. >>> >>> Yes, something like that would have worked. Thanks in advance, if you >>> do implement something of that nature. It would be useful. >> >> Can you test if this works: > > The patch you shared does /something/, but it's not clear to me what the > expected behaviour is supposed to be. Could you please comment? The idea is to add a "COMMIT MISMATCH" warning whenever we detect that two packages have different commits. What this doesn't do yet is eliminate false positives, such as different commits between a local version of a package and a remote version. I guess we are only interested in differences between remote packages, right? > Specifically, in the case of casual-dired (latest available on > melpa-stable is 1.8.2 and I have 1.8.1 installed), I observe the > following when viewing the package description: > > #+begin_quote > Other versions: 1.8.1 (installed, COMMIT MISMATCH!), 20240917.401 (melpa). > #+end_quote Does MELPA annotate their packages with commits? > > The commit that introduced the 1.8.1 version header isn't the same as > the one that was assigned the git tag, so the above makes sense. > The fact that the melpa version doesn't have a corresponding COMMIT > MISMATCH seems desirable (since there's no expectation for the melpa > version to correspond to the package header in any way). There is no causal-dired package on ELPA, so version headers don't matter here since MELPA-stable relies on Git tags. > However, when I view the package description for casual-suite (the > latest on melpa-stable is 1.6.0 and I have the same installed), I > observe: > > #+begin_quote > Other versions: 1.6.0 (melpa-stable). > #+end_quote > > > Given that the commit that introduced the 1.6.0 version in the package > header is different from the one that was tagged by the git tag, I would > have expected a COMMIT MISMATCH in the above as well. The absence of it > seems like a bug. As mentioned above, this is to be expected. MELPA ignores the Version header, and given just the tarball, we cannot detect the discrepancy you mention. > The situation gets weirder when I observe the description of htmlize. > > From the melpa archive: > > #+begin_quote > Other versions: 20240915.1657 (installed), 1.58 (nongnu, COMMIT MISMATCH!), 1.58 (melpa-stable, COMMIT MISMATCH!). > #+end_quote > > > From the melpa-stable archive: > > #+begin_quote > Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (nongnu), 20240915.1657 (melpa, COMMIT MISMATCH!). > #+end_quote > > > From the nongnu archive: > > #+begin_quote > Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (melpa-stable), 20240915.1657 (melpa, COMMIT MISMATCH!). > #+end_quote > > Could you comment on what's happening above? The fist one is fine, because you have installed the MELPA unstable package, which appears to be ahead of both the MELPA and the NonGNU version. The last two though appear to be in sync, so the commit that bumped the version tag is also the one that was tagged for release. That is why in the last two, you see that there is no MISMATCH between nongnu and melpa-stable (and vice-versa). As mentioned in my previous message, I think it might be less confusing if we just focus on mismatches between remote packages? Does this change improve that?