aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-06-26 13:13:49 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-06-26 13:13:49 -0400
commitc3c705fe7f5c04e8d2c065066e6f544f8dffafe1 (patch)
tree249abd8f784a17cbec41d5426f9593942d49c6e1 /doc
parent457d2e0710bb5512c5434228f6612724cc78d12d (diff)
followup
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment4
-rw-r--r--doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment28
2 files changed, 32 insertions, 0 deletions
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
index e1febc139..fd0a05fe2 100644
--- a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
@@ -10,4 +10,8 @@ safely.
I've done some experimentation with deleting the sqlite database when there
are unlocked files, and it seems that running `git annex fsck` manages to
recover the deleted state and restores the database.
+
+Also, since git-annex uses sqlite in WAL mode, it may be possible to
+recover the database to the last good state by deleting
+`.git/annex/keys/db-wal`. You'd still want to run `git annex fsck`.
"""]]
diff --git a/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment b/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment
new file mode 100644
index 000000000..2942dbb41
--- /dev/null
+++ b/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T16:58:17Z"
+ content="""
+I don't see the benefit to having custom commit messages for metadata
+changes. The changes are there in machine-readable format, so why
+involve a human?
+
+I agree that it would be useful to have a way to look at the metadata
+history, much as `git annex log` looks at the location history.
+
+Indeed, a lot of `git annex log` could be reused; `getAllLog` and
+`getKeyLog` are the hard part and would be reusable for metadata logs.
+The result might be something like this, when run on a file "foo":
+
+ + Thu, 22 Jun 2017 17:07:43 EST foo | author=foo
+ - Thu, 22 Jun 2017 17:07:43 EST foo | author=bar
+ + Thu, 11 Jun 2017 11:11:11 EST foo | author=bar
+
+Note that git-annex log is necessarily slow when run on a lot of files,
+because it has to run a git command per file to get the log. `git-annex log
+--all` shows a fast stream of changes from newest first, but displays the
+git-annex key that was changed, not a filename. A version of `git annex
+log` for metadata would have these same limitations.
+
+Would this help with your use case?
+"""]]