Charlie Marsh e4ec6e4025 Avoid panic when re-locking with precise commit (#5863) ... ## Summary Very subtle bug. The scenario is as follows: - We resolve: `elmer-circuitbuilder = { git = "https://github.com/ElmerCSC/elmer_circuitbuilder.git" }` - The user then changes the request to: `elmer-circuitbuilder = { git = "https://github.com/ElmerCSC/elmer_circuitbuilder.git", rev = "44d2f4b19d6837ea990c16f494bdf7543d57483d" }` - When we go to re-lock, we note two facts: 1. The "default branch" resolves to `44d2f4b19d6837ea990c16f494bdf7543d57483d`. 2. The metadata for `44d2f4b19d6837ea990c16f494bdf7543d57483d` is (whatever we grab from the lockfile). - In the resolver, we then ask for the metadata for `44d2f4b19d6837ea990c16f494bdf7543d57483d`. It's already in the cache, so we return it; thus, we never add the `44d2f4b19d6837ea990c16f494bdf7543d57483d` -> `44d2f4b19d6837ea990c16f494bdf7543d57483d` mapping to the Git resolver, because we never have to resolve it. This would apply for any case in which a requested tag or branch was replaced by its precise SHA. Replacing with a different commit is fine. It only applied to `tool.uv.sources`, and not PEP 508 URLs, because the underlying issue is that we aren't consistent about "automatically" extracting the precise commit from a Git reference. Closes https://github.com/astral-sh/uv/issues/5860.		2024-08-07 10:56:15 -04:00
..
src	Avoid panic when re-locking with precise commit (#5863)	2024-08-07 10:56:15 -04:00
Cargo.toml	Move workspace abstractions to uv-workspace crate (#5236)	2024-07-20 02:15:32 +00:00