As said, I want to use a commit id for reproducability and performance. The CI flow starts several jobs, all using the same commit id. A remote branch may be updated, and therefore considered not good (reproducible) enough as the reference here. (Regarding you proposal of using partial clones: Unfortunately, our remote server don't support filtering yet.) On Thu, Aug 17, 2023 at 9:56 PM Jeff King <peff@xxxxxxxx> wrote: > > On Thu, Aug 17, 2023 at 09:45:19PM +0200, Patrik Hägglund wrote: > > > In our CI setup, for reproducibility and performance reasons, I want > > to be able to clone a repository with only a single given commit id > > (commit hash). (Using 'git init' + 'git fetch' + 'git checkout' is > > possible, but more elaborate/low-level.) > > > > At https://lore.kernel.org/git/MN2PR12MB3616C1F2E97A18547740651DF9E29@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > it is stated that: > > > > > Never mind, I see, feature exists but server needs to allow it. Sigh. > > > > However, I'm not able to find this in the Git documentation. Can > > someone point out how to configure this? Can this be better > > documented? > > I'd use a shallow clone with depth 1, like: > > git clone -b $your_branch --depth 1 $remote_url > > Note that "--depth" implies --single-branch, so it will really just grab > that one branch (and if it's the remote's default branch that you want, > you can omit the "-b $your_branch" part). > > If you find the shape of history useful (e.g., your CI wants to look at > just new commits), you might also find partial clones useful. Something > like: > > git clone --filter=blob:none $remote_url > > will fetch all commits and trees, but only load blobs on-demand (so > basically whatever is needed to check out that tip commit). You can > pare it down further by switching to "--filter=tree:0", which will avoid > trees (but note that filling in trees when you need them is a bit more > expensive, since inherently you have to make a round-trip to the server > for each level of tree). > > -Peff
