lix-project/lix

Fork 61

lix regression for running flake update from within git rebase due to GIT_DIR environment variable #1135

New issue

Closed

opened 2026-02-23 18:01:26 +00:00 by benaryorg · 8 comments

benaryorg commented

2026-02-23 18:01:26 +00:00

Describe the bug

I have recently moved a system from NixOS 25.11 to NixOS unstable while also using Lix main.
Running nix flake update is running into very confusing issues now when run from within git rebase (more infos on the workflow leading to this below).
Effectively the git rev-list --max-count=1 refs/heads/main running against the cached repo (~/.cache/nix/gitv3) will fail with the below error on my local machine, or a similar error in a sandbox, as long as the GIT_DIR envvar is set to the current directory:

fatal: ambiguous argument 'refs/heads/main': both revision and filename

Steps To Reproduce

The following is a hopefully reasonably well documented reproducer shellscript.
Run this within a sandbox to reproduce.

shell script reproducer

#!/bin/sh

# set to 1 for verbose nix flake output
verbose=

git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git config --global advice.defaultBranchName false
mkdir git
cd git
git init --bare
git worktree add --orphan ../tree
cd ../tree
git commit --allow-empty -m "initial commit"
git checkout --detach
git branch -D tree
root=$(git rev-parse @)
git log

cat <<END

the git directory now has one empty commit (henceforth referred to as root) on a branchless HEAD
root=$root

next we'll:

- add one more commit for a gitignore
- create the flake with one input
	- use an outdated rev for the flake so we can update
- update the flake from within git rebase
	- for this we'll create a script which generates the necessary git rebase todo list

END

echo /.rebase > .gitignore
git add .gitignore
git commit -m gitignore
gitignore=$(git rev-parse @)

cat > flake.nix <<"END"
{
  # literally any repo
  inputs.agenix = { url = "git+https://git.shell.bsocat.net/agenix"; flake = false; };
  outputs = _: {};
}
END
git add .
nix flake update --commit-lock-file --override-input agenix 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6'
git commit --amend --no-edit
flake=$(git rev-parse @)
git --git-dir /home/benaryorg/.cache/nix/gitv3/13yxjr511x984vazzr715h896s2xh5ccgia56b7dykjli5mh8650 log --oneline -5 refs/heads/main

cat <<"END"


END

tee .rebase <<END
#!/bin/sh

# this script will write the git rebase todolist to the file provided in the argument
# the rebase will be against the root commit, hence that one is not included

exec > \$1

echo pick $gitignore # gitignore commit
echo pick $flake # flake commit
# update the flake
echo exec \${REBASE_HIDE_GIT_DIR+env -u GIT_DIR} nix flake update --commit-lock-file --refresh ${verbose:+-vvvv}



END
chmod +x .rebase

git -c "core.editor=./.rebase" rebase -i $root
git rebase --abort

cat <<END



the above rebase failed, however if we run the same again but without the GIT_DIR envvar, it succeeds




END

git -c "core.editor=env REBASE_HIDE_GIT_DIR=1 ./.rebase" rebase -i $root

shellscript output

% sandbox < reproducer
Initialized empty Git repository in /home/benaryorg/git/
Preparing worktree (new branch 'tree')
[tree (root-commit) 2ec2184] initial commit
HEAD is now at 2ec2184 initial commit
Deleted branch tree (was 2ec2184).
commit 2ec218475bff77f62fbe27b26d08e2238c7e7d9f (HEAD)
Author: Your Name <you@example.com>
Date:   Mon Feb 23 17:48:44 2026 +0000

    initial commit

the git directory now has one empty commit (henceforth referred to as root) on a branchless HEAD
root=2ec218475bff77f62fbe27b26d08e2238c7e7d9f

next we'll:

- add one more commit for a gitignore
- create the flake with one input
	- use an outdated rev for the flake so we can update
- update the flake from within git rebase
	- for this we'll create a script which generates the necessary git rebase todo list

[detached HEAD 339f7a3] gitignore
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore
warning: Git tree '/home/benaryorg/tree' is dirty
warning: creating lock file '/home/benaryorg/tree/flake.lock':
• Added input 'agenix':
    'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6' (2025-11-08)
warning: Git tree '/home/benaryorg/tree' is dirty
[detached HEAD 1c285ab] flake.lock: Add
 Date: Mon Feb 23 17:48:45 2026 +0000
 2 files changed, 32 insertions(+)
 create mode 100644 flake.lock
 create mode 100644 flake.nix


#!/bin/sh

# this script will write the git rebase todolist to the file provided in the argument
# the rebase will be against the root commit, hence that one is not included

exec > $1

echo pick 339f7a33064f45b282031af245c9a0c41eeb0a45 # gitignore commit
echo pick 1c285ab77820ee809733605a36fe4385c412b2d6 # flake commit
# update the flake
echo exec ${REBASE_HIDE_GIT_DIR+env -u GIT_DIR} nix flake update --commit-lock-file --refresh



Executing: nix flake update --commit-lock-file --refresh
warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user
fetching Git repository 'https://git.shell.bsocat.net/agenix'usage: git rev-list [<options>] <commit>... [--] [<path>...]

  limiting output:
    --max-count=<n>
    --max-age=<epoch>
    --min-age=<epoch>
    --sparse
    --no-merges
    --min-parents=<n>
    --no-min-parents
    --max-parents=<n>
    --no-max-parents
    --remove-empty
    --all
    --branches
    --tags
    --remotes
    --stdin
    --exclude-hidden=[fetch|receive|uploadpack]
    --quiet
  ordering output:
    --topo-order
    --date-order
    --reverse
  formatting output:
    --parents
    --children
    --objects | --objects-edge
    --disk-usage[=human]
    --unpacked
    --header | --pretty
    --[no-]object-names
    --abbrev=<n> | --no-abbrev
    --abbrev-commit
    --left-right
    --count
    -z
  special purpose:
    --bisect
    --bisect-vars
    --bisect-all
error:
       … while updating the lock file of flake 'git+file:///home/benaryorg/tree?ref=1c285ab77820ee809733605a36fe4385c412b2d6&rev=1c285ab77820ee809733605a36fe4385c412b2d6'

       … while updating the flake input 'agenix'

       … while fetching the input 'git+https://git.shell.bsocat.net/agenix'

       error: program 'git' failed with exit code 129
warning: execution failed: nix flake update --commit-lock-file --refresh
You can fix the problem, and then run

  git rebase --continue





the above rebase failed, however if we run the same again but without the GIT_DIR envvar, it succeeds




Executing: env -u GIT_DIR nix flake update --commit-lock-file --refresh
warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user
warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user
warning: updating lock file '/home/benaryorg/tree/flake.lock':
• Updated input 'agenix':
    'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6' (2025-11-08)
  → 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=b027ee29d959fda4b60b57566d64c98a202e0feb' (2026-02-04)
warning: committed new revision '565e4d83b4ae7990a1a3bd6f0e85009dd3b230f8'
Successfully rebased and updated detached HEAD.

Expected behavior

Running nix flake update from within git rebase -i should Just Work™ (IMHO).
Especially given that older Lix versions (specifically the one from 25.11 at time of writing) did work just fine.
This is compounded that this seems (I haven't checked too hard, my head already hurts from debugging this) to only ever trigger when using worktrees.

`nix --version` output

% nix --version
nix (Lix, like Nix) 2.95.0-9520e66
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/benaryorg/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/benaryorg/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/benaryorg/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/benaryorg/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/mc0v1gd1p4g19mdvkzycxahmjnh8ifkz-lix-2.95.0-9520e66/share

Additional context

Just to explain why this is important to me; I have several stacked branches basically inheriting each other (main ⇒ staging ⇒ unstable) with commits on them being incremental.
Rebasing all of those every time gets old real quick, so what I am doing instead is to work on worktrees where changes are actually disconnected, but keep all of those branches on a single contiguous headless worktree.
That worktree then has a .rebase file which takes care of picking the right commits and potentially does some resetting and whatnot.
This for me has become a rather useful workflow that the GIT_DIR stuff cuts into in a really weird way (easy to handle, but still weird and.… unexpected is the word I guess).

.rebase example

# I use the following to apply:
git -c "core.editor=cp .rebase" rebase --autosquash -i db43a60

pick 012006a # mir: btrfs incident
pick e0c1324 # flake: no nixpkgs aliases
pick 758ad48 # Revert "gitignore: .rebase for git workflow"
# FIXME: GIT_DIR workaround
x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv
x git update-ref TMP_PRE @
pick 6e754a8 # NixOS 25.11 inputs
# FIXME: GIT_DIR workaround
x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv
pick 76c471d # nixpkgs: fetchurl for mtu patch
pick c2ae70e # base: systemd.extraConfig is gone
pick c32b147 # mail: dovecot unit rename
pick e7d0f83 # ceph: caddy update
pick 01f3d04 # authentik patch rebase
pick 28d7f0b # nix: nix-serve-ng
pick 55232f0 # nixpkgs: systemd analyze patch rebase
pick 69b8ea3 # nixpkgs: phosh patch is upstream
pick 790c58a # overlay: bees systemd unit fix
pick 3645c57 # gnutoo: lidswitch rename
pick c402285 # ahoviewer: libpeas bump of girepository
pick ac6deb4 # git: mandatory checkExportOkFiles option
pick 5cbfd5e # net: no IPv6PrivacyExtensions networkd defaults
pick e540561 # tree: acme unit changes
f 56ed2c5 # fixup! tree: acme unit changes
x git push -f origin HEAD:update
pick ef030c5 # NixOS 25.11 stateversion
x git update-ref TMP_POST @
x git reset --hard TMP_PRE
x git merge --no-ff -m "NixOS 25.11" TMP_POST
x git update-ref -d TMP_PRE
x git update-ref -d TMP_POST
x git push -f origin HEAD:staging
# TODO: get the update finally over with
#x git push -f origin HEAD:staging
pick a1ad463 # unstable: unstable upgrades
pick 6252f42 # unstable: unstable flake inputs
# FIXME: GIT_DIR workaround
x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv
pick 3a0c5ca # unstable: asm&dart: NM conf covers wireless
pick a9b51ad # unstable: overlay: no cgit-pink
d 6c5ff3b # unstable: overlay: static zsh
pick 73de3e8 # unstable: desktop: xorg packages at toplevel
# FIXME: temporary
x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv mobile-nixos --override-input mobile-nixos "git+https://git.shell.bsocat.net/mobile-nixos?ref=refs/pull/865/head"
x git push -f origin HEAD:unstable

## Describe the bug I have recently moved a system from NixOS *25.11* to NixOS *unstable* while also using Lix *main*. Running `nix flake update` is running into very confusing issues now when run from within *git rebase* (more infos on the workflow leading to this below). Effectively the `git rev-list --max-count=1 refs/heads/main` running against the cached repo (`~/.cache/nix/gitv3`) will fail with the below error on my local machine, or a similar error in a sandbox, as long as the `GIT_DIR` envvar is set to the current directory: ```text fatal: ambiguous argument 'refs/heads/main': both revision and filename ``` ## Steps To Reproduce The following is a hopefully reasonably well documented reproducer shellscript. Run this within [a sandbox](https://git.shell.bsocat.net/infra/tree/overlay/sandbox.nix?h=e02b2939d96c9a9693457a0c41a995c4ae3a3c4a) to reproduce. <details><summary>shell script reproducer</summary> ```bash #!/bin/sh # set to 1 for verbose nix flake output verbose= git config --global user.email "you@example.com" git config --global user.name "Your Name" git config --global advice.defaultBranchName false mkdir git cd git git init --bare git worktree add --orphan ../tree cd ../tree git commit --allow-empty -m "initial commit" git checkout --detach git branch -D tree root=$(git rev-parse @) git log cat <<END the git directory now has one empty commit (henceforth referred to as root) on a branchless HEAD root=$root next we'll: - add one more commit for a gitignore - create the flake with one input - use an outdated rev for the flake so we can update - update the flake from within git rebase - for this we'll create a script which generates the necessary git rebase todo list END echo /.rebase > .gitignore git add .gitignore git commit -m gitignore gitignore=$(git rev-parse @) cat > flake.nix <<"END" { # literally any repo inputs.agenix = { url = "git+https://git.shell.bsocat.net/agenix"; flake = false; }; outputs = _: {}; } END git add . nix flake update --commit-lock-file --override-input agenix 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6' git commit --amend --no-edit flake=$(git rev-parse @) git --git-dir /home/benaryorg/.cache/nix/gitv3/13yxjr511x984vazzr715h896s2xh5ccgia56b7dykjli5mh8650 log --oneline -5 refs/heads/main cat <<"END" END tee .rebase <<END #!/bin/sh # this script will write the git rebase todolist to the file provided in the argument # the rebase will be against the root commit, hence that one is not included exec > \$1 echo pick $gitignore # gitignore commit echo pick $flake # flake commit # update the flake echo exec \${REBASE_HIDE_GIT_DIR+env -u GIT_DIR} nix flake update --commit-lock-file --refresh ${verbose:+-vvvv} END chmod +x .rebase git -c "core.editor=./.rebase" rebase -i $root git rebase --abort cat <<END the above rebase failed, however if we run the same again but without the GIT_DIR envvar, it succeeds END git -c "core.editor=env REBASE_HIDE_GIT_DIR=1 ./.rebase" rebase -i $root ``` </details> <details><summary>shellscript output</summary> ```text % sandbox < reproducer Initialized empty Git repository in /home/benaryorg/git/ Preparing worktree (new branch 'tree') [tree (root-commit) 2ec2184] initial commit HEAD is now at 2ec2184 initial commit Deleted branch tree (was 2ec2184). commit 2ec218475bff77f62fbe27b26d08e2238c7e7d9f (HEAD) Author: Your Name <you@example.com> Date: Mon Feb 23 17:48:44 2026 +0000 initial commit the git directory now has one empty commit (henceforth referred to as root) on a branchless HEAD root=2ec218475bff77f62fbe27b26d08e2238c7e7d9f next we'll: - add one more commit for a gitignore - create the flake with one input - use an outdated rev for the flake so we can update - update the flake from within git rebase - for this we'll create a script which generates the necessary git rebase todo list [detached HEAD 339f7a3] gitignore 1 file changed, 1 insertion(+) create mode 100644 .gitignore warning: Git tree '/home/benaryorg/tree' is dirty warning: creating lock file '/home/benaryorg/tree/flake.lock': • Added input 'agenix': 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6' (2025-11-08) warning: Git tree '/home/benaryorg/tree' is dirty [detached HEAD 1c285ab] flake.lock: Add Date: Mon Feb 23 17:48:45 2026 +0000 2 files changed, 32 insertions(+) create mode 100644 flake.lock create mode 100644 flake.nix #!/bin/sh # this script will write the git rebase todolist to the file provided in the argument # the rebase will be against the root commit, hence that one is not included exec > $1 echo pick 339f7a33064f45b282031af245c9a0c41eeb0a45 # gitignore commit echo pick 1c285ab77820ee809733605a36fe4385c412b2d6 # flake commit # update the flake echo exec ${REBASE_HIDE_GIT_DIR+env -u GIT_DIR} nix flake update --commit-lock-file --refresh Executing: nix flake update --commit-lock-file --refresh warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user fetching Git repository 'https://git.shell.bsocat.net/agenix'usage: git rev-list [<options>] <commit>... [--] [<path>...] limiting output: --max-count=<n> --max-age=<epoch> --min-age=<epoch> --sparse --no-merges --min-parents=<n> --no-min-parents --max-parents=<n> --no-max-parents --remove-empty --all --branches --tags --remotes --stdin --exclude-hidden=[fetch|receive|uploadpack] --quiet ordering output: --topo-order --date-order --reverse formatting output: --parents --children --objects | --objects-edge --disk-usage[=human] --unpacked --header | --pretty --[no-]object-names --abbrev=<n> | --no-abbrev --abbrev-commit --left-right --count -z special purpose: --bisect --bisect-vars --bisect-all error: … while updating the lock file of flake 'git+file:///home/benaryorg/tree?ref=1c285ab77820ee809733605a36fe4385c412b2d6&rev=1c285ab77820ee809733605a36fe4385c412b2d6' … while updating the flake input 'agenix' … while fetching the input 'git+https://git.shell.bsocat.net/agenix' error: program 'git' failed with exit code 129 warning: execution failed: nix flake update --commit-lock-file --refresh You can fix the problem, and then run git rebase --continue the above rebase failed, however if we run the same again but without the GIT_DIR envvar, it succeeds Executing: env -u GIT_DIR nix flake update --commit-lock-file --refresh warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-negative-ttl', because it is a restricted setting and you are not a trusted user warning: Ignoring the client-specified setting 'narinfo-cache-positive-ttl', because it is a restricted setting and you are not a trusted user warning: updating lock file '/home/benaryorg/tree/flake.lock': • Updated input 'agenix': 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=fcdea223397448d35d9b31f798479227e80183f6' (2025-11-08) → 'git+https://git.shell.bsocat.net/agenix?ref=refs/heads/main&rev=b027ee29d959fda4b60b57566d64c98a202e0feb' (2026-02-04) warning: committed new revision '565e4d83b4ae7990a1a3bd6f0e85009dd3b230f8' Successfully rebased and updated detached HEAD. ``` </details> ## Expected behavior Running `nix flake update` from within `git rebase -i` should Just Work™ (IMHO). Especially given that older Lix versions (specifically the one from 25.11 at time of writing) did work just fine. This is compounded that this seems (I haven't checked too hard, my head already hurts from debugging this) to only ever trigger when using worktrees. ## `nix --version` output ```console % nix --version nix (Lix, like Nix) 2.95.0-9520e66 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/benaryorg/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/benaryorg/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/benaryorg/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/benaryorg/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/mc0v1gd1p4g19mdvkzycxahmjnh8ifkz-lix-2.95.0-9520e66/share ``` ## Additional context Just to explain why this is important to me; I have several stacked branches basically inheriting each other (*main* ⇒ *staging* ⇒ *unstable*) with commits on them being incremental. Rebasing all of those every time gets old real quick, so what I am doing instead is to work on worktrees where changes are actually disconnected, but keep all of those branches on a single contiguous headless worktree. That worktree then has a *.rebase* file which takes care of picking the right commits and potentially does some resetting and whatnot. This for me has become a rather useful workflow that the `GIT_DIR` stuff cuts into in a really weird way (easy to handle, but still weird and.… *unexpected* is the word I guess). <details><summary>.rebase example</summary> ```bash # I use the following to apply: git -c "core.editor=cp .rebase" rebase --autosquash -i db43a60 ``` ```bash pick 012006a # mir: btrfs incident pick e0c1324 # flake: no nixpkgs aliases pick 758ad48 # Revert "gitignore: .rebase for git workflow" # FIXME: GIT_DIR workaround x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv x git update-ref TMP_PRE @ pick 6e754a8 # NixOS 25.11 inputs # FIXME: GIT_DIR workaround x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv pick 76c471d # nixpkgs: fetchurl for mtu patch pick c2ae70e # base: systemd.extraConfig is gone pick c32b147 # mail: dovecot unit rename pick e7d0f83 # ceph: caddy update pick 01f3d04 # authentik patch rebase pick 28d7f0b # nix: nix-serve-ng pick 55232f0 # nixpkgs: systemd analyze patch rebase pick 69b8ea3 # nixpkgs: phosh patch is upstream pick 790c58a # overlay: bees systemd unit fix pick 3645c57 # gnutoo: lidswitch rename pick c402285 # ahoviewer: libpeas bump of girepository pick ac6deb4 # git: mandatory checkExportOkFiles option pick 5cbfd5e # net: no IPv6PrivacyExtensions networkd defaults pick e540561 # tree: acme unit changes f 56ed2c5 # fixup! tree: acme unit changes x git push -f origin HEAD:update pick ef030c5 # NixOS 25.11 stateversion x git update-ref TMP_POST @ x git reset --hard TMP_PRE x git merge --no-ff -m "NixOS 25.11" TMP_POST x git update-ref -d TMP_PRE x git update-ref -d TMP_POST x git push -f origin HEAD:staging # TODO: get the update finally over with #x git push -f origin HEAD:staging pick a1ad463 # unstable: unstable upgrades pick 6252f42 # unstable: unstable flake inputs # FIXME: GIT_DIR workaround x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv pick 3a0c5ca # unstable: asm&dart: NM conf covers wireless pick a9b51ad # unstable: overlay: no cgit-pink d 6c5ff3b # unstable: overlay: static zsh pick 73de3e8 # unstable: desktop: xorg packages at toplevel # FIXME: temporary x env -u GIT_DIR nix flake update --commit-lock-file --no-use-registries --refresh -vvvv mobile-nixos --override-input mobile-nixos "git+https://git.shell.bsocat.net/mobile-nixos?ref=refs/pull/865/head" x git push -f origin HEAD:unstable ``` </details>

benaryorg added the

bug

label

2026-02-23 18:01:26 +00:00

benaryorg commented

2026-02-23 18:20:18 +00:00

Author

I also think that Lix should keep passing on GIT_DIR to any calls to git underneath as long as they touch the current repository. There should only ever be an attempt to isolate the git calls which deliberately deal with a different repository. The cache repositories and their operations should not be influenced by anything going on in the context of the flake repository they are a dependency of IMHO.

Oh, just to be clear, I have no idea whether this is a Lix-specific bug, or whether some change in git may have caused unintended side-effects, if this turns out to be an actual issue in the way git is handling things then of course I don't think Lix needs to change anything really. This bug is only filed against Lix because it does (seemingly) use the git from *PATH*, meaning that when I run the older version of Lix and it succeeds, this is likely due to a change in Lix, not git itself. I also think that Lix should keep passing on `GIT_DIR` to any calls to git underneath as long as they touch the current repository. There should only ever be an attempt to isolate the git calls which deliberately deal with a different repository. The cache repositories and their operations should not be influenced by anything going on in the context of the flake repository they are a dependency of IMHO.

pennae commented

2026-02-23 18:50:55 +00:00

Owner

after the first setup block of your script (up to and excluding the first comment cat) this reproduces with

GIT_DIR=/tmp/bo/git/worktrees/tree git -C ~/.cache/nix/gitv3/13yxjr511x984vazzr715h896s2xh5ccgia56b7dykjli5mh8650 rev-list --max-count=1 refs/heads/main

but flipping the directories (env vs -C arg) fixes it too. definitely a git issue. considering the amount of bustage we've seen with worktrees that's not super suprising :/

after the first setup block of your script (up to and excluding the first comment cat) this reproduces with ```sh GIT_DIR=/tmp/bo/git/worktrees/tree git -C ~/.cache/nix/gitv3/13yxjr511x984vazzr715h896s2xh5ccgia56b7dykjli5mh8650 rev-list --max-count=1 refs/heads/main ``` but flipping the directories (env vs -C arg) fixes it too. definitely a git issue. considering the amount of bustage we've seen with worktrees that's not super suprising :/

benaryorg commented

2026-02-23 19:19:16 +00:00

Author

@pennae wrote in #1135 (comment):

but flipping the directories (env vs -C arg) fixes it too. definitely a git issue.

It just clicked for me; -C isn't the right argument for Lix to pass here. Lix should use --git-dir (which is what GIT_DIR does), since -C only makes all paths interpreted as relative to that directory¹, while --git-dir is an authoritative "use this git repository" which is what all the git commands Lix invokes are meant to do. Since --git-dir has higher precedence than GIT_DIR this also fixes things down the line. I'm not sure if there's any operation in which Lix depends on the actual path, rather than just the repository, but if there is, both parameters should be provided.
Which, surprise twist, is what ~~the old Lix version does~~ all other git commands used by Lix seem to do (I totally missed that interaction when going through the logs):

Running 'git' '-C' '/home/benaryorg/.cache/nix/gitv3/1x85vq3w1kpmbd068wppdk681530bx55vyygx54vk8f6df64cmk6' '--git-dir' '.' 'symbolic-ref' '--' 'HEAD' 'refs/heads/main'

It does use -C to change the directory, and then specifies --git-dir to be . which is interpreted relative to the -C argument.
Which raises the question why this ~~was changed~~ is different for rev-list.?

Edit: sorry, the log of the old Lix version bails due to a different error exactly one command earlier, the versions do more or less the same thing².

Quoting git(1): This option affects options that expect path name like --git-dir and --work-tree in that their interpretations of the path names would be made relative to the working directory caused by the -C option. ↩︎
The older version did bail during testing due to issues with packed refs, which the new version seems to be fine with, other than a lot of could not update mtime for file '' warnings. ↩︎

@pennae wrote in https://git.lix.systems/lix-project/lix/issues/1135#issuecomment-17621: > but flipping the directories (env vs -C arg) fixes it too. definitely a git issue. It just clicked for me; `-C` isn't the right argument for Lix to pass here. Lix should use `--git-dir` (which is what `GIT_DIR` does), since `-C` only makes all paths interpreted as relative to that directory[^git-c], while `--git-dir` is an authoritative "use this git repository" which is what all the git commands Lix invokes are meant to do. Since `--git-dir` has higher precedence than `GIT_DIR` this also fixes things down the line. I'm not sure if there's any operation in which Lix depends on the actual path, rather than just the repository, but if there is, both parameters should be provided. Which, surprise twist, is what ~~the old Lix version does~~ *all other git commands used by Lix seem to do* (I totally missed that interaction when going through the logs): ```text Running 'git' '-C' '/home/benaryorg/.cache/nix/gitv3/1x85vq3w1kpmbd068wppdk681530bx55vyygx54vk8f6df64cmk6' '--git-dir' '.' 'symbolic-ref' '--' 'HEAD' 'refs/heads/main' ``` It does use `-C` to change the directory, and then specifies `--git-dir` to be `.` which is interpreted relative to the `-C` argument. Which raises the question why this ~~was changed~~ *is different for rev-list*.? *Edit*: sorry, the log of the old Lix version bails due to a different error exactly one command earlier, the versions do more or less the same thing[^packed-refs]. [^git-c]: Quoting *git(1)*: This option affects options that expect path name like `--git-dir` and `--work-tree` in that their interpretations of the path names would be made relative to the working directory caused by the `-C` option. [^packed-refs]: The [older version did bail during testing due to issues with packed refs](https://github.com/NixOS/nix/issues/8822), which the new version seems to be fine with, other than a lot of `could not update mtime for file ''` warnings.

pennae commented

2026-02-23 19:26:03 +00:00

Owner

Which raises the question why this was changed.?

okay, so this is probably 6bf187537a then. before that change we never shelled out to git to read refs, after that we do (and that new command indeed does not set --git-dir, all others do). goot grief

> Which raises the question why this was changed.? okay, so this is probably 6bf187537ac094181b25ad96137e83cf31cfa356 then. before that change we never shelled out to git to read refs, after that we do (and that new command indeed does not set `--git-dir`, all others do). goot grief :dragnupsidedown:

benaryorg commented

2026-02-23 19:38:00 +00:00

Author

I've got a patch over at my lix fork.

x86_64-linux: ✅
aarch64-linux: ✅

The regular package tests all pass fine.
Running the reproducer against the patched version yields two successful rebases.
Locally the new build also works as it used to.
nix flake check fails over unrelated matters.
All of hydraJobs.tests (at least those having an out attr) are passing.
I'll go ahead and push the change to gerrit.

I've got a patch over at [my lix fork](https://git.lix.systems/benaryorg/lix/src/branch/worktree-rebase-git-dir-thing). - [`x86_64-linux`](https://hydra.cloud.bsocat.net/build/918625/nixlog/1/tail): ✅ - [`aarch64-linux`](https://hydra.cloud.bsocat.net/build/918591/nixlog/1/tail): ✅ The regular package tests all pass fine. Running the reproducer against the patched version yields two successful rebases. Locally the new build also works as it used to. `nix flake check` fails over unrelated matters. All of `hydraJobs.tests` (at least those having an *out* attr) are passing. I'll go ahead and push the change to gerrit.

lix-bot commented

2026-02-23 21:11:14 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/5252 ("libfetchers: Provide gitDir for rev-list operation")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/5252](https://gerrit.lix.systems/c/lix/+/5252) ("libfetchers: Provide gitDir for rev-list operation")

benaryorg commented

2026-02-25 18:07:37 +00:00

Author

I didn't ask before, but why does this use rev-list --max-count=1 instead of rev-parse which I think would do the same thing?

I didn't ask before, but why does this use `rev-list --max-count=1` instead of `rev-parse` which I think would do the same thing?

pennae commented

2026-02-25 23:09:45 +00:00

Owner

not entirely sure, but since rev-parse is notionally a frontend to rev-list it does make sense to directly use the low-level tool for the low-level job. (we're more confused that it sets --max-count=1 instead of --no-walk, but since both work why bother)

not entirely sure, but since `rev-parse` is notionally a frontend to `rev-list` it does make sense to directly use the low-level tool for the low-level job. (we're more confused that it sets `--max-count=1` instead of `--no-walk`, but since both work why bother)

👍 1