Added a comment
authornobodyinperson <nobodyinperson@web>
Thu, 10 Aug 2023 01:08:16 +0000 (01:08 +0000)
committeradmin <admin@branchable.com>
Thu, 10 Aug 2023 01:08:16 +0000 (01:08 +0000)
doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment [new file with mode: 0644]

diff --git a/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment b/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
new file mode 100644 (file)
index 0000000..1ed45ab
--- /dev/null
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-08-10T01:08:16Z"
+ content="""
+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 remote`s 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 `dead` and then `forget --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.
+"""]]