Hi Xiyue,

Thanks for the bug report.

On 12/11/2025 5:51 am, Xiyue Deng wrote:
Latest uscan gives wrong result when d/watch tracks HEAD of a remote repository.

    * What exactly did you do (or not do) that was effective (or
      ineffective)?
As an example of emacs-dart-mode, both the v4 and v5 d/watch that tracks
HEAD gives the wrong result.

v4:
,----
| version=4
| opts="mode=git, pgpmode=none, pretty=1.0.7+git%cd.%h" \
|     https://github.com/emacsorphanage/dart-mode \
|     HEAD debian uupdate
`----

v5:
,----
| Version: 5
|
| Source: https://github.com/emacsorphanage/dart-mode
| Matching-Pattern: HEAD
| Mode: git
| Pgp-Mode: none
| Pretty: 1.0.7+git%cd.%h
`----

uscan converts version 4 watch files to version 5, so seeing the same behaviour is expected.

The following is from the output of `uscan --report-status`:
,----
| $ uscan --report-status
| uscan info: Scan watch files in .
| uscan info: Check debian/watch and debian/changelog in .
| uscan info: package="emacs-dart-mode" version="1.0.7+git20250811.edb45cb-1" 
(as
| seen in debian/changelog)
| uscan info: package="emacs-dart-mode" version="1.0.7+git20250811.edb45cb" (no 
ep
| och/revision)
| uscan info: ./debian/changelog sets package="emacs-dart-mode" 
version="1.0.7+git
| 20250811.edb45cb"
| uscan info: Process watch file at: debian/watch
|     package = emacs-dart-mode
|     version = 1.0.7+git20250811.edb45cb
|     pkg_dir = .
| uscan info: Parsing gitpretty: 1.0.7+git%cd.%h
| uscan info: Parsing mode: git
| uscan info: Parsing pgpmode: none
| uscan info: Last orig.tar.* tarball version (from debian/changelog): 
1.0.7+git20
| 250811.edb45cb
| uscan info: Last orig.tar.* tarball version (dversionmangled): 
1.0.7+git20250811
| .edb45cb
| uscan warn: Using upstreamvcs remote origin

I see you are using the new git upstream repository mode introduced in 2.25.23. This mode operates on cloned repositories and only fetches new commits.

Previously, this mode only supported tagged repositories.

| uscan info: Looking at $base        = 
https://github.com/emacsorphanage/dart-mod
| e with
|     $filepattern        = HEAD found
|     $newfile            = HEAD
|     $mangled_newversion = 1.0.7+git20251110.ca232ba
|     $newversion         = 1.0.7+git20251110.ca232ba
|     $lastversion        = 1.0.7+git20250811.edb45cb
| uscan info: Upstream URL(+tag) to download is identified as    
https://github.co
| m/emacsorphanage/dart-mode HEAD
| uscan info: Filename (filenamemangled) for downloaded file: 
emacs-dart-mode-1.0.
| 7+git20251110.ca232ba.tar.xz
| Newest version of emacs-dart-mode on remote site is 
1.0.7+git20251110.ca232ba, l
| ocal version is 1.0.7+git20250811.edb45cb
|  => Newer package available from:
|         => https://github.com/emacsorphanage/dart-mode HEAD
| uscan info: Scan finished
`----

Note that it reports the newversion as `1.0.7+git20251110.ca232ba', but
the actual latest commit of upstreamvcs happened on `Tue Nov 4 21:43:39
2025 -0800', and the latest commit hash should be 22288d0, so the
correct version string should be `1.0.7+git20251105.22288d0'.  And as a
matter of fact, the qa.debian.org page reports the correct version
string[1], suggesting that some previous version of uscan was working
correctly.

    * What was the outcome of this action?
On closer inspect, `ca232ba' is actually the latest commit of my
debian/latest branch on Salsa.  So it looks like when tracking HEAD,
uscan is using my `debian/latest' branch instead of the remote branch
for getting the latest commit time and hash.
Interesting. Can you please post (or link to) the output of `git remote --verbose show` and `uscan -vv`?
    * What outcome did you expect instead?

Restoring the previous correct behavior would be great.

As this would generate the wrong version string and potentially wrong
packaging, I'm setting the severity as important.

[1] https://qa.debian.org/cgi-bin/watch?pkg=emacs-dart-mode

Debian QA shows the correct version if we were to clone the repository, and it matches what uscan generates when cloning. The issue is specific to the upstream repository mode.

Hugh

Reply via email to