{"thread":{"id":"65804","subject":"Re: [PATCH] clone: accept DEPTH env var as fallback for --depth","startedAt":"2026-06-13T17:43:35Z","lastAt":"2026-06-14T01:08:26Z","messageCount":2,"participants":["Hadrien Loge","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"545465","messageId":"CADeHOfw6kNstNFucG7an6+Mbm2+=-PnOH8xtZkO9RK8=eWsx=w@mail.gmail.com","threadId":"65804","inReplyTo":null,"subject":"Re: [PATCH] clone: accept DEPTH env var as fallback for --depth","fromName":"Hadrien Loge","fromEmail":"hadrien.loge@gmail.com","sentAt":"2026-06-13T17:43:23Z","receivedAt":"2026-06-13T17:43:35Z","isPatch":true,"body":"Well mainly I'm asking this for packaging (Arch/Alpine/Etc)\nThese all follow similar conventions (PKGBUILD/APKBUILD).\n\nBut in nested flows the ENV var seems like the proper solution.\n\nMainly I gave this example on github:\n\n    git clone --depth 1 url dest\n    cd dest\n    bash run.sh\n    here run.sh has its own clone deps (perhaps even multiple)\n    --depth 1 is now lost\n\nAnd only ENV vars that I can think of properly propagate for CI\nflows/clean chroot envirs.\nThank you for considering the solution. It would be very useful\nfor speeding up packaging.\nEven on 5k commits history it's 900kb vs 17mb.\n\nI have also reworked the commit to include tests/docs.\nand rename to GIT_CLONE_DEPTH\n\nKind regards,\nHade\n"},{"id":"545472","messageId":"ai3_CEstWqtw51MF@fruit.crustytoothpaste.net","threadId":"65804","inReplyTo":"CADeHOfw6kNstNFucG7an6+Mbm2+=-PnOH8xtZkO9RK8=eWsx=w@mail.gmail.com","subject":"Re: [PATCH] clone: accept DEPTH env var as fallback for --depth","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-06-14T01:08:24Z","receivedAt":"2026-06-14T01:08:26Z","isPatch":true,"body":"On 2026-06-13 at 17:43:23, Hadrien Loge wrote:\n> Well mainly I'm asking this for packaging (Arch/Alpine/Etc)\n> These all follow similar conventions (PKGBUILD/APKBUILD).\n\nDebian builds packages without network access because they want to make\nsure that every piece of the source is in the source package, that every\npackage is reproducibly built, and that users can rebuild source\npackages if they like without worrying about needing network access or\nhaving their location exposed to the author.\n\nWouldn't that be the right decision for reproducibility and privacy\nreasons?  If so, then the download of the source would happen before\nbuilding and could be tailored to meet your needs with the existing\ncommand-line option.\n\n> But in nested flows the ENV var seems like the proper solution.\n> \n> Mainly I gave this example on github:\n> \n>     git clone --depth 1 url dest\n>     cd dest\n>     bash run.sh\n>     here run.sh has its own clone deps (perhaps even multiple)\n>     --depth 1 is now lost\n> \n> And only ENV vars that I can think of properly propagate for CI\n> flows/clean chroot envirs.\n> Thank you for considering the solution. It would be very useful\n> for speeding up packaging.\n> Even on 5k commits history it's 900kb vs 17mb.\n> \n> I have also reworked the commit to include tests/docs.\n> and rename to GIT_CLONE_DEPTH\n\nSo say someone has this set in their environment and then they run a\nscript that clones a repository and runs `git describe`.  That no longer\nworks and the script fails because it assumed that it had history.\n\nIt's also a problem if you then do a fetch into the shallow repository\nbecause shallow fetches are _extremely_ expensive to serve (more\nexpensive than full clones), so having automation that now runs\nthousands of these shallow fetches means that your requests will be\nthrottled by the server operator whereas they wouldn't with a regular\nfetch.\n\nThere's no one right solution here and while I am sympathetic to your\nsituation, it will also result in hard-to-reproduce breakage for other\ntooling.  People rely on `git clone` and similar commands only honouring\ncommand line arguments.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}