On Aug 27, 2024 12:07 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> > On 2024-08-26 21:28:38 -0700 (-0700), Otto Kekäläinen wrote: > > 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. > [...] > > Maybe, but only if you want authorship, release note or changelog > generation truncated at 99 commits worth of information at build > time. Take OpenStack Nova for example, which has historically > averaged around a thousand non-merge commits between major releases > every 6 months; --depth=99 would be an order of magnitude too low to > find just one major release's worth of notes and tags on a stable > branch. > > Granted, this is why upstream in OpenStack we recommend package > maintainers use our source distribution changelogs rather than > rebuilding source themselves from code from version control. Our > community considers our version control to be an implementation > detail of our development workflow, not the primary means of > supplying source code to downstream consumers. Where version control > is concerned, we consider our source code to include the full Git > metadata and not merely the files held in the worktree. For a > hassle-free source distribution, we extract that metadata and > incorporate the relevant parts as files in our signed source > tarballs. > -- > Jeremy Stanley All you wrote is precisely why I am not using these tarballs. I know we don't agree... :) Also, the FTP master do NOT want the changeLog as they are too big and provide no value when one can check the git repo to find the same info. Thomas Goirand (zigo)
