Maximilian Bosch
04daff94e3
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
830 B
830 B
synopsis, issues, credits, category
| 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
refwas prefixed withrefs/headsunless it starts withrefs/itself.Now, this is not done if the
reflooks like a commit hash. -
Specifying
builtins.fetchGit { ref = "a-tag"; /* … */ }was broken becauserefs/headswas appended.Now, the fetcher doesn't turn a ref into
refs/heads/ref, but intorefs/*/ref. That way, the value inrefcan be either a tag or a branch. -
The ref resolution happens the same way as in git:
- If
refs/refexists, it's used. - If a tag
refs/tags/refexists, it's used. - If a branch
refs/heads/refexists, it's used.
- If