In the past we've decided that fetchGit should require a ref if you're pulling from a non-master branch. I don't really want to change that since it will requiring cloning an entire repository rather than a single branch.

... it will requiring cloning an entire repository rather than a single branch.

Why does it require cloning an entire repository?

Only fetching rev like I do here should be enough no?

Also when both specifying a rev and a ref I now check if rev is an ancestor of ref. I'm careful to only fetch ref when rev is not an ancestor of the already cached ref.

BTW the reason I need this is that in naersk we need to fetch crates with a git source. However since crates only specify a rev we don't have a ref available.

I currently work around this by setting ref = rev but that results in ugly git warnings like:

warning: refname '9ec3a6973f6a17dc4b2566520253fc6203f75ac6' is ambiguous.
Git normally never creates a ref that ends with 40 hex characters
because it will be ignored when you just specify 40-hex. These refs
may be created by mistake. For example,

  git switch -c $br $(git rev-parse ...)

where "$br" is somehow empty and a 40-hex ref is created. Please
examine these refs and maybe delete them. Turn this message off by
running "git config advice.objectNameWarning false"

Git in general does not allow fetching an arbitrary revision from a remote for security reasons. (IIRC there is a server setting to disable this check.) You have to specify a ref that contains the revision.

TIL that git servers indeed don't allow fetching revisions directly by default (GitHub however does).

So if this is parameterizable on the server, what about making it parameterizable on the client as well?

I forced-pushed a proposal for this where I introduce the fetchRevInsteadOfRef argument to builtins.fetchGit (I'm open for other names). It defaults to false to keep backwards compatibility and to mimic the default on the server. When fetchRevInsteadOfRef == true builtins.fetchGit fetches the specified rev directly instead of fetching ref.

This keeps the old semantics, although with the additional ancestor checks, but allows fetching revisions directly.

@edolstra WDYT?

@basvandijk GitHub does not allow fetching 'unadvertised refs' (one of the heads or tags, basically), which is the git default. We work around this by specifying ref = "*"; where needed and setting rev to the revision, does that work for you? Alternatively, fetchTarball will work on non-private github repos and usually download less data.

@yorickvP what's the ref="*" about? Is that an instruction to nix to perform a full clone first? Or is that a git thing?

$ git fetch origin '*'
fatal: invalid refspec '*'

It's a git thing, git fetch origin 'refs/heads/*'. Also see #2409

I marked this as stale due to inactivity. → More info

I closed this issue due to inactivity. → More info