From owner-freebsd-questions@freebsd.org Mon Jan 11 14:45:03 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8B62B4DB52A for ; Mon, 11 Jan 2021 14:45:03 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDxM33PyBz3mgN; Mon, 11 Jan 2021 14:45:03 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 48A6E224F; Mon, 11 Jan 2021 14:45:03 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from PD0786.local (130.31-255-62.static.virginmediabusiness.co.uk [62.255.31.130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id D8FD21C5DB; Mon, 11 Jan 2021 14:45:00 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/D8FD21C5DB; dkim=none; dkim-atps=neutral Subject: Re: github ports To: Erwan David , freebsd-questions@freebsd.org References: <94ddb7c7d79c1614761fee4c28aaf367.squirrel@webmail.harte-lyne.ca> <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org> From: Matthew Seaman Message-ID: <1746973c-e7c0-9ce3-a3cd-12ba239c597a@FreeBSD.org> Date: Mon, 11 Jan 2021 14:44:59 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 14:45:03 -0000 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