• 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 - #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 #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%20repo, 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%25, 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