Otto Kekäläinen <o...@debian.org> writes: > On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote: >> On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote: >> [...] >>> I think a shallow clone of depth 1 is sufficient, although that's not >>> sufficient to get the correct version number from Git in all cases. >> [...] >> >> Some tools (python3-reno, for example) want to inspect the commits >> and historical tags on branches, in order to do things like >> assembling release notes documents. I don't know if any reno-using >> projects packaged in Debian get release notes included, but if they >> do then shallow clones would break that process. The python3-pbr
> You could use --depth=99 perhaps? > Usually the difference of having depth=1 or 99 isn't that big unless > there was a recent large refactoring. Git repositories that are very > big (e.g. LibreOffice, MariaDB) have hundreds of thousands of commits, > and by doing a depth=99 clone you avoid 99.995% of the history, and in > projects where changelog/release notes is based on git commits, then > 99 commits is probably enough. I suppose that's *possible*, but I'd want to see some concrete survey evidence to support that. I'm fairly sure that 99 would be insufficient to build a change log on some of my small packages for which I'm a single developer in all cases, let alone a project with any significant commit volume and a policy of separating unrelated changes into separate commits. My guess is that the sweet spots are --depth=1 and a full checkout, it's not generally possible to tell which a given package needs in advance (in other words, it's best handled as a configuration option), and it's probably not worth the effort to mess around with any intermediate depth. I suspect we'll find that the vast majority of packages work fine with --depth=1, and the remaining cases should just use a full checkout to avoid creating fragile assumptions that may work today and break tomorrow. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
