lix/doc/manual/rl-next/fetchGit-regression.md
Maximilian Bosch 04daff94e3
libfetchers/git: restore compat with builtins.fetchGit from 2.3
Since fb38459d6e, each `ref` is appended
with `refs/heads` unless it starts with `refs/` already. This regressed
two use-cases that worked fine before:

* Specifying a commit hash as `ref`: now, if `ref` looks like a commit
  hash it will be directly passed to `git fetch`.

* Specifying a tag without `refs/tags` as prefix: now, the fetcher prepends
  `refs/*` to a ref that doesn't start with `refs/` and doesn't look
  like a commit hash. That way, both a branch and a tag specified in
  `ref` can be fetched.

  The order of preference in git is

  * file in `refs/` (e.g. `HEAD`)
  * file in `refs/tags/`
  * file in `refs/heads` (i.e. a branch)

  After fetching `refs/*`, ref is resolved the same way as git does.

Change-Id: Idd49b97cbdc8c6fdc8faa5a48bef3dec25e4ccc3
2024-09-28 14:52:06 +02:00

830 B

synopsis issues credits category
restore backwards-compatibility of `builtins.fetchGit` with Nix 2.3
5291
5128
ma27
Fixes

Compatibility with builtins.fetchGit from Nix 2.3 has been restored as follows:

  • Until now, each ref was prefixed with refs/heads unless it starts with refs/ itself.

    Now, this is not done if the ref looks like a commit hash.

  • Specifying builtins.fetchGit { ref = "a-tag"; /* … */ } was broken because refs/heads was appended.

    Now, the fetcher doesn't turn a ref into refs/heads/ref, but into refs/*/ref. That way, the value in ref can be either a tag or a branch.

  • The ref resolution happens the same way as in git:

    • If refs/ref exists, it's used.
    • If a tag refs/tags/ref exists, it's used.
    • If a branch refs/heads/ref exists, it's used.