[ulysses4ever]

Fixes #12523: a source-repository-package from git now downloads only the commit that its tag or branch names, instead of that commit's whole history. Below is the longer story from your friendly AI engine (Opus 5.5).

---

Since #10254 (cabal 3.16), cabal clones with --depth=1, which gets the tip of the default branch, and then runs git fetch origin <tag> without --depth. In a shallow repository, that fetches the whole history of the pinned commit, so unless the pin is the tip, the shallow clone saves little. This passes --depth=1 to that fetch as well.

A complete checkout stays complete. Git ignores --depth when it clones a plain local path, and such a checkout is what the other stanzas for the same repository borrow objects from through --reference (#12296). A --depth=1 fetch would make it shallow and stop the sharing, so the fetch passes --depth=1 only when .git/shallow exists.

Packages now see only the pinned commit. Tags were already missing before this change: on master, git describe fails in the checkout too. A package that needs the history or the tags can use post-checkout-command: git fetch --depth=2147483647 --tags, which the docs now describe. git fetch --unshallow would make the next sync fail, because by then the checkout is complete.

Testing

• The git tests in cabal-install:test:long-tests: syncSourceRepos, shallow, distinct tags now pins a tag with two commits of history and checks that every checkout has one commit; the local-path case checks for the full history. Without the change, the test fails with expected: 1, but got: 2.
• End to end, with a project pinning a commit two behind the tip of a repository over file://: master's checkout has 3 commits and this branch's has 1. With the post-checkout-command above, the checkout has 3 and git describe works, also after the pin moves to the tip; with git fetch --unshallow --tags instead, that second sync fails with exit code 128.

Not covered: submodules are still fetched in full, and so is the default branch on later syncs. Abbreviated hashes still fail, as they did before (#10605).

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

QA Notes

In an empty directory, write a cabal.project with

optional-packages: ./*.cabal

source-repository-package
  type: git
  location: https://github.com/haskell/containers
  tag: <the full hash of a commit well behind the default branch>
  subdir: containers

and run cabal build --dry-run containers. Then git -C dist-newstyle/src/contain*/ rev-list --count HEAD prints 1; with cabal 3.16 to 3.18, it prints the number of commits up to the pinned one.

🤖 Generated with Claude Code

https://claude.ai/code/session_0176vAefrw8jPKXdh9h1wKuj