Weihang Lo

https://github.com/rust-lang/cargo/pull/13960 is the culprit of this regression. We do `git ls-files` for every package unconditionally after that PR. When `-Zpackage-workspace` is stabilized, the issue will be more prominent.

Going to do a refactor on moving this out from the package loop. @rustbot claims

Did some profiling. Detailed report in https://github.com/rust-lang/cargo/pull/14962. To summarize, we were doing `git status` and comparing dirty files against each package to be published. aws-rust-sdk has 400+ members so such...

If we skipped the entire git status check (the `--allow-dirty` behavior prior to #13960), the profiling data would look like this: 

#14962 was closed because we found more bugs in `cargo package` VCS dirtiness check, showing in #14967. If #14962 merged those bugs would be harder to fix.

> if we assume most repos are clean, could we ask git if the repo is clean and bypass these checks, only doing them if the repo is dirty? Cargo...

A complete fix of the regression might be Cargo offering a `--no-vcs-info`, which skips every checks about VCS. I can't see any other approach could really restore the same performance...

> In our publishing step we now `rm -rf .git/` before running `cargo package` and that has taken a full workspace publish from ~3 hours to ~15 minutes. That is...

@epage See for a glance. I believe it would be at least 3x faster by just looking the proportion of each trace.

This is still not entirely fixed. The latest update made it less bad, but you still need to collect status for all repos