after git reset --hard, git-annex get of unlocked unpopulated pointer file does nothing

Please describe the problem.

situation is tricky as I forced it via git reset --hard HEAD^ after a commit which managed to commit a file directly into git instead of git-annex due to changes in .gitattributes , whenever originally it was under annex unlocked.

So now I am in situation where it is not obvious on how to "instantiate" that file in the tree since annex get does nothing although file is just a link:

❯ cat .strava-backup/config.toml
/annex/objects/MD5E-s1235--04d86de671070073b0bade06fd5085c1.toml
❯ git annex whereis .strava-backup/config.toml
whereis .strava-backup/config.toml (1 copy) 
    abe1a028-2aec-4c31-b48d-0db92e338292 -- yoh@bilena:~/proj/strava-backup-mine [here]
ok
❯ git annex get .strava-backup/config.toml
❯ git annex get --force .strava-backup/config.toml
❯ git annex restage .strava-backup/config.toml
git-annex: This command takes no parameters.
❯ git annex restage
restage  ok
❯ cat .strava-backup/config.toml
/annex/objects/MD5E-s1235--04d86de671070073b0bade06fd5085c1.toml

I thought I could just "instantiate" its content from the key -- but now git-annex insists (well - via git status) that it is modified, even after I do restage and commit.

❯ cat .git/annex/objects/F2/m8/MD5E-s1235--04d86de671070073b0bade06fd5085c1.toml/MD5E-s1235--04d86de671070073b0bade06fd5085c1.toml >| .strava-backup/config.toml
❯ git status
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   .strava-backup/config.toml

no changes added to commit (use "git add" and/or "git commit -a")
❯ git annex restage
restage  ok
❯ git status
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   .strava-backup/config.toml

no changes added to commit (use "git add" and/or "git commit -a")
❯ git diff
❯ git diff --cached
❯ git status
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   .strava-backup/config.toml

no changes added to commit (use "git add" and/or "git commit -a")
❯ git commit -m 'reinstantiated file'
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   .strava-backup/config.toml

no changes added to commit (use "git add" and/or "git commit -a")
❯ git commit -m 'reinstantiated file' -a
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
❯ git status
On branch master
Your branch is ahead of 'test-washoe-tmp/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   .strava-backup/config.toml

no changes added to commit (use "git add" and/or "git commit -a")

only if I do git reset --hard it becomes unmodified . I had to do annex fsck which made it instantiated but modified, then "commit" which committed nothing but everything became kosher.

There should be a more seamless way to recover, or should I generally always use annex fsck after git reset --hard when working with unlocked files?

What version of git-annex are you using? On what operating system?

❯ git annex version | head -n 1
git-annex version: 10.20251114-geeb21b831e7c45078bd9447ec2b0532a691fe471

fixed --Joey

RSS Atom

comment 1

git-annex get is not doing anything because the content of the annexed file is already present in the repository, as shown by the git-annex whereis. All that get does is get objects that are not present in the git-annex repository. It does not fix up after other problems.

As far as I can tell, this will reproduce your situation:

git-annex init
git config annex.addunlocked true
echo 1 > foo
git-annex add foo
git commit -m add
echo 2 > foo
git config annex.largefiles nothing
git annex add foo
git commit -m add
git config annex.largefiles anything
git reset --hard HEAD^

The command you could have run then, which would have fixed it right up, is git status. That will populate the files with their annexed content. And it will recommend running git-annex restage to fix up the index to reflect those changes. (Running git-annex restage on its own is useless though.)

This all happens because git reset --hard does not run any git hooks. So git-annex smudge --update does not get a chance to automatically run like it usually would when a checkout or merge is made. Until that git status.

Running git-annex smudge --update after the git reset will also fix things right up.

Comment by joey — Wed Dec 31 16:23:36 2025

comment 2

I can understand reaching for git-annex get in this situation. But I don't know if it really makes sense to have that and every other command that gets the content of a file also handle populating annex pointer files that have been staged. That seems like it might very well violate least surprise in other situations, or cause problems in other situations.

The best fix would be if git reset, git stash, git cherry-pick and whatever else were made to run some hook.

One could just as well complain about this:

git-annex add foo
mkdir subdir
git mv foo subdir/
cat subdir/foo
cat: subdir/foo: No such file or directory
git-annex get subdir/foo
cat subdir/foo
cat: subdir/foo: No such file or directory

There git-annex get does not fix up the annex symlink for the new location of the file. The situation will get resolved by git-annex fix which gets run on git commit and is usually enough that the user doesn't need to remember to run it.

Not only is it out of scope for git-annex get to deal with that situation, if it modified the symlink it would then leave a change in the working tree. Which is surprising behavior.

Comment by joey — Wed Dec 31 17:29:42 2025

comment 3

I think it makes sense for git-annex fix to deal with this situation. In both cases the user has run a git command that affects files in the workint tree, and it has left the annexed content not accessible.

Comment by joey — Thu Jan 1 16:17:58 2026

Add a comment