Paket.Core 12.0.0-alpha005

• net10.0

  • Chessie (>= 0.6.0)
  • Fake.IO.FileSystem (>= 6.2.0 && < 7.0.0)
  • FSharp.Core (>= 9.0.303)
  • Mono.Cecil (>= 0.11.6 && < 0.12.0)
  • Newtonsoft.Json (>= 13.0.4)
  • Nuget.Packaging (>= 7.9.0)
  • System.Net.Http.WinHttpHandler (>= 10.0.14)
  • System.Security.Cryptography.ProtectedData (>= 10.0.14)

Git dependencies restore again when the git cache doesn't have their repository yet, as on a fresh CI agent: since 11.0.0, Paket ran `git remote set-url` in the empty cache folder that its lock had created - https://github.com/fsprojects/Paket/issues/4461
The paket-files of a git dependency are checked out when the HEAD of its git cache names a branch that is gone, as after the repository renamed its default branch, instead of failing with "bad revision 'HEAD'"
A git dependency whose checkout failed, as for a file name too long for the file system, is cloned again at the next restore, instead of being taken for one with local changes or for an up-to-date one
A local git dependency without a branch, whose repository has no master, gets an error that suggests giving its branch, as in `git file:///path/to/repository main`
A process that Paket starts and that exits right away, such as a git command, the `build:` command of a git dependency or a credential provider, no longer fails with "Start of process ... failed". For a local git repository, the error showed as "Could not find hash for ..."
Local git dependencies with a Windows path, like `git file:///C:/code/repo`, resolve again: since 11.0.0 and https://github.com/fsprojects/Paket/pull/4377, their path kept the `/` before the drive letter
A broken git cache in `~/.paket/git/db` is set up again instead of making git change the repository of a parent folder, such as a dotfiles repository in the home folder, and the git cache works with `safe.bareRepository=explicit`
The path of a local git repository can escape characters, like `git file:///home/me/my repo`, and its folder name is read from a Windows path that ends with `\` or doesn't exist yet, and from a path to the `.git` folder of the repository, like `git file:///home/me/repo/.git`. Such a path used to give an empty or a whole path as the name of the git cache and paket-files folders. A repository at the root of a file system, which has no folder name, or whose path ends with `.` or `..`, fails with an error. A folder name that holds a `%`, like `git file:///home/me/100%`, is checked out too
A paket-files folder of a git dependency that isn't a clone, as one committed with the project, is cloned again. Paket used to run its git commands on the repository of the project instead, and could check the dependency out over the project
A git dependency on an annotated tag is locked at the commit of the tag, not at the tag object, which made each restore download it again. A lock file that holds the tag object still restores, and gets the commit at the next update
Only the `.git` that ends the name of a git repository, in any case as in `Repo.GIT`, is left out of its folder name, so `git https://github.com/me/me.github.io.git` goes to `paket-files/github.com/me/me.github.io` instead of `mehub.io`. The paket-files folder of a repository with `.git` inside its name, or another case of `.git` at its end, moves. A remote URL to the `.git` folder of a repository, like `git ssh://host/home/me/repo/.git`, is named after the folder of the repository, as a local one is, instead of taking the paket-files folder of its owner
The git cache of a repository is `~/.paket/git/db/<owner>/<project>`, so that remote repositories of the same name from two owners no longer share one, and swap its branches on each fetch. Local repositories of the same folder name still share one. Each repository is cloned again once, and `paket clear-cache` removes the old caches
`paket install` no longer rewrites the framework restrictions of unchanged packages in paket.lock when it saves it for another reason, such as a removed `github` file, in groups with a `framework:` line: these restrictions are written in a single, shorter form, without empty clauses like `(&& (== net10.0) (== net461))`. The restrictions of the dependencies are rewritten once at the next `paket install`, and those of the packages when their group is resolved again; they hold the same frameworks
The restore no longer rewrites `.paket/Paket.Restore.targets` when only its line endings differ from the ones of Paket, as after a checkout with other line endings, which showed it as changed in git after each restore. The same goes for `.paket/paket.targets` and the other files that the restore writes
When the restore updates `.paket/Paket.Restore.targets`, as for a new version of Paket, the file keeps its line endings instead of taking the ones of the machine that built Paket. The same goes for `.paket/paket.targets` and the other files that the restore writes