fetchers/git: make relative path absolute for local repo

[bryango]

Motivation

Closes #9708 (again).

This patch:

• (naively) Resolves relative paths to local git repos, returning absolute paths, thus allowing flake URIs such as git+file:./${submodule} to continue working.
• Adds tests to prevent future breakages.

Context

Flake URIs such as git+file:./${submodule} used to work before 2.18, but broke in 2.19, was fixed later, and broke again recently since 3e0129c, resulting in a core-dumped assertion error in #9708 (comment).

This PR suppresses the error and allows git+file:./${submodule}to continue working. However, this fix is not ideal and should potentially be superseded by a better submodule implementation in the future. See:

• Flake input git+file:./${submodule} no longer works #9708
• libutil/url: fix git+file:./ parse error #9897

A better fix is outlined by @roberth in https://discourse.nixos.org/t/57783, namely:

This bug seems to have allowed relative git flake inputs to be resolved against the current working directory (as in POSIX), and this tends to work out ok in the context of flakes, but is the wrong behavior, as it should resolve against the flake.nix base directory instead.
Supporting relative paths in fetchTree would add significant value.
This behavior was used as a workaround for lacking relative flake input or “subflake” support.

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

Friendly pings:

• @roberth and @tomberek for reviews
• @DamienCassou and @aij for testing

[aij]

I gave it a quick try and it does work for me:

ivan@tobati:~/nixops/aij$ /nix/store/bn0djaymav6qa4zg5vaskzcaija5nq2p-nix-2.26.0pre20241227_9111645/bin/nix flake update 
warning: updating lock file '/home/ivan/nixops/aij/flake.lock':
• Updated input 'unstable':
    'git+file:unstable?rev=3f0036916daca9836ba2c3f236b0ae051949a0a8' (2024-12-21)
  → 'git+file:unstable?ref=refs/heads/ipmiutil&rev=174ae1b581ddd6d5a6c55684da392e0baf500b1e' (2024-12-27)

[roberth]

Partial fix

[edolstra]

For the example in #9709, namely

inputs.nixpkgs.url = git+file:./nixpkgs;

doesn't this result in a lock file that has the absolute path of the original Git repo in it? I.e. if I run nix flake lock on such a flake in /home/bob/repo, doesn't it result in a lock file that references /home/bob/repo/nixpkgs?

[bryango]

inputs.nixpkgs.url = git+file:./nixpkgs;

doesn't this result in a lock file that has the absolute path of the original Git repo in it? I.e. if I run nix flake lock on such a flake in /home/bob/repo, doesn't it result in a lock file that references /home/bob/repo/nixpkgs?

@edolstra Actually, no! It still gets locked to the relative path and shows up in flake.lock as file:./nixpkgs, which is great! I have pushed another test to cement this behavior.

[bryango]

submodule does get locked to the relative path file:./submodule. I don't understand why but hey, it works!

[bryango]

Draft-ing and un-draft-ing to try to unlock the new CI...
Update: doesn't seem to work, no idea what I should do now haha

[roberth]

Rebased for GHA config update

[bryango]

Rebased on current master, conflicts resolved, CI happy! Friendly ping @roberth @edolstra for re-review!

[bryango]

Rebased again, conflicts resolved, CI happy.

[roberth]

Thanks!

@mergify queue