Re: Some feedback on 'git clone create'

From: Justin Tobler <jltobler@gmail.com>
Date: Dec 4, 2024, 23:19 UTC
Message-ID: <pgz37cgfssouykfqxvmjt6pc2lycta6tmyjkovsceqwibww4fw@424usnt3dlh2>
In-Reply-To: <AfLIcOv4X1AxLOaODNS89HA-bMeI7bj0xUGsLD-6xmVAS_a_2xOzy2uX-wXxpNA7kCpKYudELCEKv73roW_-HTd83Fcz3FZ_yJQOswQHW48=@calamity.inc>

On 24/12/04 05:28AM, Sainan wrote:

Show 5 quoted lines

> Hi, I hope this email finds you well.
> 
> I think Git bundles/packfiles are an exceptional compression format, but I find there are some rough edges with the tool to create them:
> 
> 1. There is no way to specify that you want a shallow bundle, instead you are only able to a) pack the entire tree at a given head or b) pack new/updated objects in a specified range. Anecdotally, this could store data in ~67% of the size of an equivalent .zip file.

You can create an incremental bundle covering a specified range. Something like the following example might help you achieve what you are looking for:

  $ git bundle create inc.bundle main~10..main

Show 5 quoted lines

> 
> 2. It seems that when specifiying a commit hash, it raises an error:
> $ git bundle create repo.bundle $(git rev-list HEAD | head -n 1)
> > fatal: Refusing to create empty bundle.
> This confuses me slightly because I thought a commit hash should also be a valid head _pointer_. 'git rev-list' also seems to agree with me on this.

A bundle is essentially a pack file with a header indicating the references contained within the bundle. If no reference is provided, the bundle is considered empty and git refuses to create it. I think this makes sense in the context of unbundling as you probably would not want to add new objects without updating references in the target repository.

From the git-bundle(1) docs for "create", the usage does say it accepts <git-rev-list-args> which may be a bit misleading because git-rev-list(1) does consider the commit hash as valid. Maybe that should be updated to indicate that proper references are expected.

-Justin