Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jan 2021 14:44:59 +0000
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        Erwan David <erwan@rail.eu.org>, freebsd-questions@freebsd.org
Subject:   Re: github ports
Message-ID:  <1746973c-e7c0-9ce3-a3cd-12ba239c597a@FreeBSD.org>
In-Reply-To: <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org>
References:  <mailman.98.1610366402.21235.freebsd-questions@freebsd.org> <94ddb7c7d79c1614761fee4c28aaf367.squirrel@webmail.harte-lyne.ca> <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 11/01/2021 14:17, Erwan David wrote:

> But a big drawback is that as defauklt you get the whole history, which 
> the moajority of us do not need and that some people cannot handle (not 
> enough space, not enough bandwidth).

If you do a shallow clone of the repository (as Steve suggested 
upthread) eg:

    git clone --depth 1 --single-branch 
git@github.com:freebsd/freebsd-ports.git

then the amount of disk space used should be roughly similar to what 
you'ld use for portsnap(8) (including the bits portsnap uses under /var 
as well as what's in /usr/ports).  At least, extrapolating from some 
investigations done comparing freebsd-update(8) and a similar shallow 
clone of the src repository.

Tools like gitup will effectively do this sort of checkout for you. (In 
ports as net/gitup, but beware: it's so new the paint is still wet, and 
it probably has quite a bit of debugging still to do before it is 
production ready.)  gitup has been proposed as a possible BSD-licensed 
tool to be bundled with the OS as a native way to pull down the system, 
ports and other sources.  There's also OpenBSD's 'got' which uses the 
same repository format as `git` but assumes the sort of development 
process the OpenBSD people use currently.

The first clone of the repo will be pretty bandwidth intensive, and also 
not something you can restart from where you got to if your session gets 
interrupted in the middle.  There are plans afoot to supply snapshots of 
the repositories as tarballs that you can pull down via fetch(8), which 
will support resuming a download.  That might not be available for ports 
until after the ports cuts over from SVN though.

Subsequently updating via `git pull` should be pretty bandwidth 
efficient -- you will literally download the exact changes needed to 
take your existing checkout to the latest version from the upstream repo.

Over time, as you repeatedly `git pull` the disk usage will tend to 
creep up a bit, but you can use `git gc --aggressive` to garbage collect 
and minimize disk space usage.

	Cheers,

	Matthew



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?1746973c-e7c0-9ce3-a3cd-12ba239c597a>