80 lines
2.9 KiB
Markdown
80 lines
2.9 KiB
Markdown
Intro
|
|
=====
|
|
|
|
This experience report
|
|
describes steps I've taken for recovering from a situation where
|
|
an *unrelated* git-annex's remote was accidentally merged into a repository.
|
|
|
|
It is posted to the forum for use by anyone who finds themselves in the same situation
|
|
(especially myself…).
|
|
|
|
The root cause of the issue was a copy-pasted `git remote add` gone wrong,
|
|
and a subsequent `git annex sync`, that "contaminated" the rest of my remotes.
|
|
That led to `git annex info` showing the union of all the repositories available to the two repositories,
|
|
and `fsck --all` runs looking for files from any repository.
|
|
|
|
It should go without saying, but here it is anyway:
|
|
|
|
**Following these steps can eventualy lead to data loss**.
|
|
|
|
The precautions I've taken are
|
|
|
|
* knowing that two complete copies of the data sets exist,
|
|
* having a filesystem level snapshot of a least one of those copies, and
|
|
* not starting any file dropping until all remotes have completed fscks at the end.
|
|
|
|
Identifying the last good state
|
|
===============================
|
|
|
|
By looking for the first occurrence of the UUID of one of the bad new remotes
|
|
in `git log --patch git-annex`,
|
|
I've identified the last good git-annex state before the merge.
|
|
|
|
Tagging that as `git tag before-accidental-merging-with-other-server 83c1b945c2428cefa968aec587229f6a87649de6`.
|
|
|
|
|
|
Removing potentially mergable information
|
|
=========================================
|
|
|
|
git-annex is eager to pull in updates lying around --
|
|
while this is usually a good thing,
|
|
here it incurs the danger of resurrecting the accident.
|
|
|
|
On all remotes that were accessed since the accident,
|
|
I've executed this to remove both the local synced/git-annex branch
|
|
and any memory of cached remote branches:
|
|
|
|
$ git branch -D synced/git-annex
|
|
$ git branch -r | sed 's@remotes/@@' | xargs git branch -d -r
|
|
|
|
and restore the git-annex branch:
|
|
|
|
$ git branch -f git-annex 83c1b945c2428cefa968aec587229f6a87649de6
|
|
|
|
That proved to be insufficient --
|
|
after I had first only done this,
|
|
things looked good for a while and then after the first `git annex fsck --fast`,
|
|
the remotes were back again.
|
|
|
|
The only file large enough to contain the offending data in .git/annex was .git/annex/index,
|
|
so I've removed that backed by [[internals]]' statement of it being safe to remove:
|
|
|
|
$ rm .git/annex/index
|
|
|
|
(did that on all remotes; on bare ones it's `annex/index`, obviously).
|
|
|
|
Verification
|
|
============
|
|
|
|
To ensure everyone is on the same page,
|
|
I've run `git annex sync`;
|
|
its speed already showed that now there's no information about a second repository being transferred.
|
|
|
|
Subsequently, I've run `git annex fsck --all` in all locations.
|
|
(That *did* show that I should previously have marked some keys as dead when they were migrated from SHA256E to SHA256,
|
|
but that's beside the point here).
|
|
|
|
Even after a sync following the above,
|
|
no traces of the bad merge (be it in the form of a repository or of a file from there) have shown up any more.
|
|
|
|
-- [[chrysn]]
|