Please describe the problem.
I did an interactive rebase of the git-annex branch and rolled back the remote git-annex branch. Afterwards git annex sync
did not merge the remote git-annex branch.
What steps will reproduce the problem?
git init a
cd a
git annex init
git commit -m . --allow-empty
cd ..
git clone a b
cd b
git annex init
git remote rename origin a
cd ../a
git annex fsck
cd ../b
git annex sync
git push a :synced/git-annex
git push -f a 'git-annex^2:git-annex'
git branch -f git-annex 'git-annex^1'
git annex sync
After the second sync, a/git-annex
did not get merged.
What version of git-annex are you using? On what operating system?
8.20211011 linux
This kind of thing generally doesn't work because you have not updated .git/annex/index, so the next time git-annex updates the git-annex branch after that branch has been manually modified, it merges in the contents of that index, which tends to roll back the modifications. So I am doubtful that whatever you were trying to do would really have worked.
What is happening here is that .git/annex/mergedrefs is used to keep track of refs that have previously been merged into the git-annex branch. And it contains the hash of a/git-annex. So, git-annex knows it's merged that before and avoids merging it again. But of course, you fooled it by forcing the local git-annex branch to back before that merge happened.
If you delete .git/annex/mergedrefs file, it will merge. Or the problem will self-correct after some more changes to the git-annex branch happen in the a repo, causing a/git-annex to get ahead of the previous merge point.
The mergedrefs file is a speed hack, see 154c9398309b52789bf15f6f6204cb22b0ffec82.
I suppose this problem could be avoided by recording the sha of the git-annex branch that the mergedrefs were merged into, and ignoring mergedrefs if the branch sha is not the same. Although it would then need to advance that recorded sha every time it modified the git-annex branch, which would be extra work.