1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
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]]
|
