Maximilian Bosch
04daff94e3
Sincefb38459d6e, 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
24 lines
830 B
Markdown
24 lines
830 B
Markdown
---
|
|
synopsis: restore backwards-compatibility of `builtins.fetchGit` with Nix 2.3
|
|
issues: [5291, 5128]
|
|
credits: [ma27]
|
|
category: 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.
|