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
830 B
830 B
synopsis | issues | credits | category | |||
---|---|---|---|---|---|---|
restore backwards-compatibility of `builtins.fetchGit` with Nix 2.3 |
|
|
Fixes |
Compatibility with builtins.fetchGit
from Nix 2.3 has been restored as follows:
-
Until now, each
ref
was prefixed withrefs/heads
unless it starts withrefs/
itself.Now, this is not done if the
ref
looks like a commit hash. -
Specifying
builtins.fetchGit { ref = "a-tag"; /* … */ }
was broken becauserefs/heads
was appended.Now, the fetcher doesn't turn a ref into
refs/heads/ref
, but intorefs/*/ref
. That way, the value inref
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.
- If