sneak/sfdupes
1
0
Fork 0
Code Issues 3 Pull Requests 1 Actions 10 Packages Projects Releases Wiki Activity

Install from @latest, retract v0.0.1, print a go-installed binary's version (closes #116)
check / check (push) Waiting to run
Details

Browse Source 
README "Install" now leads with go install ...@latest: until 1.0 each
release is a v0.0.N tag on main's tip, so @latest gives that tip once
it has passed the build. It also says what @main and v0.0.1 give and
how to check an installed binary. go.mod retracts v0.0.1, the early
build without a database.

sfdupes --version printed "dev" for every go-installed binary, since
only the linker set Version. When the linker sets none, it now prints
the main module's version from runtime/debug.ReadBuildInfo; "dev" is
left only when neither is known. Version is now empty by default.

The retraction takes effect only once a release carrying it is the
newest.

Model: opus-5-5
This commit was merged in pull request #130.
This commit is contained in:
clawbot
2026-10-17 05:44:49 +02:00
parent 4e4a94db2b
commit 6346319701
5 changed files with 112 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+33 -8
View File
@@ -49,15 +49,40 @@ results are as fresh as the last completed scan.
### Install
With Go installed, this builds and installs the current `main` branch:
With Go installed, this builds and installs the newest release:
```sh
go install sneak.berlin/go/sfdupes@latest
```
Until 1.0, releases are `v0.0.N` tags on the tip of the `main` branch: each time
`main` moves and its tip passes `script/cibuild`, that tip is tagged with the
next `v0.0.N`. So `@latest` installs `main`'s tip once it has passed the build.
`@main` installs the tip before it is tagged:
```sh
go install sneak.berlin/go/sfdupes@main
```
The binary goes to `$(go env GOPATH)/bin`, or to `$GOBIN` when that is set. A
binary installed this way reports its version as `dev`; one built from a clone
or into the Docker image carries the git tag or commit it was built from.
`v0.0.1` is an early build without a database. It does not work as this README
describes, and `go.mod` retracts it.
The binary goes to `$(go env GOPATH)/bin`, or to `$GOBIN` when that is set. To
see which version an installed binary is:
```sh
sfdupes --version
go version -m "$(command -v sfdupes)"
```
`sfdupes --version` prints `sfdupes VERSION`. For a binary from `go install`,
`VERSION` is the version Go recorded in it: the release tag, such as `v0.0.3`,
or for `@main` a pseudo-version ending in the first 12 characters of the
commit's hash. A binary built from a clone or into the Docker image carries the
git tag or commit it was built from instead, and `VERSION` is `dev` only when
the binary carries no version at all. `go version -m` prints what Go recorded in
the binary; its `mod` line names the module's version. Binaries from `v0.0.2`
and earlier print `dev`, so check those with `go version -m`.
From a clone, `make build` writes the binary to `./sfdupes`:
@@ -262,10 +287,10 @@ sfdupes [command] --help
CPUs), `-x` (`--one-file-system`) keeps the walk of each operand on that
operand's filesystem, and `--no-default-excludes` lets the walk enter the
default excludes, a list of paths; all three are described under "`scan` mode".
`sfdupes --version` (or `-v`) prints one line, `sfdupes VERSION`, to stdout and
exits 0, writing nothing to stderr. `-h` or `--help`, alone or after a
subcommand, prints the help text to stderr and exits 0, writing nothing to
stdout.
`sfdupes --version` (or `-v`) prints one line, `sfdupes VERSION` (see
"Install"), to stdout and exits 0, writing nothing to stderr. `-h` or `--help`,
alone or after a subcommand, prints the help text to stderr and exits 0, writing
nothing to stdout.
### Database