--local implied for clones between different drives preventing shallow clones and filling up disks

[TobiSchluter]

• I was not able to find an open or closed issue matching what I'm seeing

(I'm placing this in the Git for windows issue tracker, as this is what the executable identifies itself as. I don't believe this is specific to Windows)

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Windows Terminal

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

$ git clone  --single-branch --branch feature/bla --depth 200 ~/source/Repos/bla /e/bla
Cloning into './bla'...
warning: --depth is ignored in local clones; use file:// instead.
... run out of disk space ...

• What did you expect to occur after running these commands?

I expect to get a shallow clone. The implied --local is wrong or useless (depending on one's view), as I'm cloning to a different drive (a USB stick). It seems a bad choice to override the explicit thing the user asked for and just do something else instead, even with a warning. And in this case A) the rationale for overriding the user ("it's a local copy") doesn't apply and B) it leads to a potentially dangerous outcome (writing orders of magnitude more data than the user intended)

• What actually happened instead?

It tries to clone the full history, which besides taking ages makes my USB stick run out of memory.

[TobiSchluter]

Using a shallow clone with file:// is really slow. It takes much longer for the first 100 MB in the shallow clone using file:// than it took for the non-shallow clone to run out of disk space. I assume that a shallow clone means some additional work beyond copying a number of files, but it seems to be orders of magnitude slower now which is most likely due to file:://.

[dscho]

This is not a Windows-specific issue. Please take it to the Git mailing list (send plain-text messages, HTML messages are dropped silently).

[TobiSchluter]

Done, thanks https://lore.kernel.org/git/f06d2964-3af2-425c-a68d-803ede45ee08@schlueters.de/T/#u