Say I have two unrelated videos repositories. Say that, by some mistake of history, one was added as the git remote of the other. I somehow managed to clean the git history and disentangle the files between the two repos.
Now git-annex still thinks about that other repository. I can mark it as dead, but it will still have location tracking information for all the files of the other repository.
I know about git-annex-forget: I'm not sure it's what I want. I do not want to "[throw] away historical data about past locations of files", I would actually want to keep historical location data for relevant files. I want to forget a repository ever existed.
Is that possible?
Marking it with git-annex-dead doesn't cut it, from what I understand. In what to do when you lose a repository, joeyh seemed to say "dead is the best we can do", as "the automatic merging used on the git-annex branch tends to re-add lines that are deleted in one repo when merging with another that still has them." But now we have something like forget, could that be coerced into forgetting just a subset of stuff?
Thanks! -- anarcat
This has happened repeatedly to me and I feel your pain. It is especially likely to happen when using submodules, which can sometimes be uninitialized, so when you enter them and modify
git remotes from there, you're actually messing up the parent repo.I'm afraid there's no convenient way to purge git annex remotes except marking as
deadand thenforget --drop-dead, which loses past location history as well.What you can do though is trying to manually kick the bad commit out of the git-annex branch (e.g.
git rebase -i), then force-push the git-annex branch to all remotes. If you miss one remote, the bad commit will be reintroduced somewhen later.git-annex forget --drop-deadis probably the best answer.Yes, this also deletes historical data about past locations of files. The only user-visible effect of that is that
git-annex logwon't show where files used to be located.It has to delete history, because history includes all the data that was merged from the other repository. And it would be too hard to traverse all history and delete any information that came from that repository in every commit.
In my testing, I have found
git annex forget --drop-dead --forceproblematic because if ever the two repositories speak to one another (thru e.g. fetch) again, the very alive remote for one marked dead in the other will be eradicated.Luckily I've learned that you don't have to fetch from one remote to another to still issue "informed" annex commands which is critical. In other words, I didn't appreciate how annex learns of file content in remotes dynamically, I thought it was fairly dependent on merging in the
git-annexbranch to learn about files. Instead you can confidently treatfetch,pull,pushcommands as all exclusively for the merging of two sibling repos (and their histories, settings, remotes, etc).For these kinds of ("friend"?) remotes (unrelated remotes), I think you'll want to remove the fetch refspec entirely and add
annex-sync=falseif you want to keep the relationship around, otherwise never runsyncuntil you remove unrelated remotes.