Shallow clones break cabal.project containing same repo twice

[adamgundry]

Describe the bug
If a cabal.project file contains two source-repository-package stanzas for the same repo, with different commits, cabal will try to download the repo once and then make a local clone (to checkout the other commit). Since the change to use a shallow clone for the original download, this local clone step fails.

To Reproduce
Create a new directory with the following cabal.project (or pick your favourite git repo with two commits, the actual contents are irrelevant):

source-repository-package
  type: git
  location: git@github.com:adamgundry/units-parser.git
  tag: d2fa872b2d56ea3abc1ca1a3b4da2653a0a767b9

source-repository-package
  type: git
  location: git@github.com:adamgundry/units-parser.git
  tag: 0cadd53539d693abf127788e06ec534ac0c7b0f4

$ cabal-3.18.1.0 build
Cloning into '/tmp/cabal-bug/dist-newstyle/src/units-par_-06079f32ba2a27b9f2a555f8d23a8ad27a57aaa6ab544c8fb2d189d1547c6932'...
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 15 (delta 0), reused 8 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (15/15), 12.16 KiB | 12.16 MiB/s, done.
remote: Enumerating objects: 145, done.
remote: Counting objects: 100% (145/145), done.
remote: Compressing objects: 100% (51/51), done.
remote: Total 134 (delta 67), reused 116 (delta 52), pack-reused 0 (from 0)
Receiving objects: 100% (134/134), 15.41 KiB | 15.41 MiB/s, done.
Resolving deltas: 100% (67/67), completed with 6 local objects.
From github.com:adamgundry/units-parser
 * branch            0cadd53539d693abf127788e06ec534ac0c7b0f4 -> FETCH_HEAD
HEAD is now at 0cadd53 CI: Test GHC 9.2.8 through GHC 9.12.2
Cloning into '/tmp/cabal-bug/dist-newstyle/src/units-par_-06079f32ba2a27b9f2a555f8d23a8ad27a57aaa6ab544c8fb2d189d1547c6932-2'...
fatal: reference repository '/tmp/cabal-bug/dist-newstyle/src/units-par_-06079f32ba2a27b9f2a555f8d23a8ad27a57aaa6ab544c8fb2d189d1547c6932' is shallow

Expected behavior
I assume we want to continue using shallow clones by default, but either we need to use full clones when the same repo appears twice, or avoid using git clone --reference for the local copy step.

System information

• Operating system: Linux
• cabal version 3.18.1.0 (also exists in 3.16 but this worked in 3.12 when shallow clones were not used)

Additional context
Somewhat related to #10605, #10639. But note here that the reproducer uses full hashes, not tags.

[Mikolaj]

@adamgundry: I assume the same repo twice in cabal.project is useful for two package in one repo? Does the error manifest also when you explicitly mention different directories? Or is there a good reason to use precisely what you have there? Because maybe could fix this by banning some kinds of repetition?

[adamgundry]

Yes, this is useful for two packages in a single repo. The same error arises when the subdir is different for each source-repository-package (the important thing is that the commits are different). One could even imagine a single repo that had different packages at the root on different commits, which would be a bit weird but should in principle work.

Of course the common case is for both checkouts to use the same commit, and that's probably a reasonable workaround in many cases.

[ulysses4ever]

@Mikolaj that's a wrong regression-label.

I remember this or very similar issue surfaced right after the feature was merged, and I believe it was fixed. Someone needs to dig the history...

[ulysses4ever]

Original report: #10254 (comment)

I had a draft fixing it but died when trying to test it…. #11921

[ulysses4ever]

i'm working on reviving #11921 now, hope to be done today.