Yes, testing local changes with `srpm` is the main use case. I would even say that using
`scratch-build` without `--srpm` is a typical mistake for new packagers - thinking they
test before they push, when in effect they don't.
Testing (scratch-building) the pushed head makes sense when there are/were koschei
warnings, or updates to related packages and you want to know whwther your package still
builds (would build) as is, say before a mass rebuild.
And as you point out, checking out the pushed head gives you almost that at the expense of
an srpm rebuild, which is not exactly the same as scratch-building the "original
srpm".
`--srpm` is named misleadingly, by the way, because it names the "transport of the
source" when indeed it implies a potentially different source version. That's
another reasons why removing it (the name) and making it the mode of operation for
`scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an srpm for
technical reasons.
- `build` is about building something pushed, and `--scratch` only changes where it is
build.
Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope so, and
I'm really wondering whether any srpm-mode should belong to that command at all.
It's much clearer if `build` deals with sources "in the buildsystem" only,
and {copr,scratch,local,mock}-build with the local sources. (Yes, `local` and `mockbuild`
could have helpful aliases, too.)