Recently (at some point since mid-July; but I don't know the exact version when it started) in my two library repos Cargo has started failing when attempting to cargo publish, with the error:

$ cargo publish
    Updating crates.io index
error: 1 files in the working directory contain changes that were not yet committed into git:

Cargo.lock

to proceed despite this, pass the `--allow-dirty` flag

However, this is incorrect because:

1. This is a library, so Cargo.lock should not be committed or published.
2. Cargo.lock is in .gitignore.
3. Cargo.lock has never been checked in to Git.

For confirmation:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ git log Cargo.lock
[no output]

$ git rm --cached Cargo.lock
fatal: pathspec 'Cargo.lock' did not match any files        

$ cat .gitignore
Cargo.lock
target/

cargo publish fails in the same way/with the same error.

As a workaround, deleting Cargo.lock entirely allows publishing (and of course since it's a library it can just be safely recreated afterwards).

The two repositories where I have observed this happening are https://github.com/felixc/rexiv2 and https://github.com/felixc/gexiv2-sys. I tried to reproduce it by creating a minimal empty repo but was not immediately able to, so I'm not sure what part of the repo configuration is leading to this. Some discussion on Discord suggested it might have to do with the runnable examples/ targets leading to some mis-detection as a binary crate rather than a library one?

Notes

$ cargo version
cargo 1.37.0 (9edd08916 2019-08-02)

$ rustup --version
rustup 1.18.3 (435397f48 2019-05-22)

$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
beta-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
1.20.0-x86_64-unknown-linux-gnu

$ uname -a
Linux mir 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux