Added a comment
authorgioele@678b7c03f524f2669b179b603f65352fcc16774e <gioele@web>
Sat, 25 Mar 2023 08:47:01 +0000 (08:47 +0000)
committeradmin <admin@branchable.com>
Sat, 25 Mar 2023 08:47:01 +0000 (08:47 +0000)
doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment [new file with mode: 0644]

diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment
new file mode 100644 (file)
index 0000000..9e7aba1
--- /dev/null
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 5"
+ date="2023-03-25T08:47:01Z"
+ content="""
+> I wonder if there are other situations where modifications can prevent checkout of the updated adjusted branch?
+
+I clearly remember seeing something similar when a `sync` failed due a non-recoverable network failure. Unfortunately I have no logs from that day.
+
+> It seems wise for git-annex to defend against it in depth, by making sure no crash can leave it in detached head state.
+
+Perhaps also extend `fsck` to automatically recover from such a state? Or at least suggest a couple of possible solutions to the user?
+"""]]