From d92ec5c1d69552ac42d84672653d5eee7adb918b Mon Sep 17 00:00:00 2001 From: "vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717" Date: Thu, 5 Apr 2018 21:01:51 +0000 Subject: [PATCH 1/2] Added a comment --- ...nt_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment diff --git a/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment new file mode 100644 index 0000000000..b7edd53e40 --- /dev/null +++ b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717" + nickname="vrs+annex" + avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c" + subject="comment 2" + date="2018-04-05T21:01:51Z" + content=""" +I have no opinion about what backend to use. If doing it via the metadata system significantly slows down things though and is generally awkward, why not build a separate subsystem? + +I don't know what you mean by \"look over all the merged changes and go off and frob timestamps\", but as long as n is on the order of [number of files changed in the commit], updating n files' timestamps sounds reasonable? There's the question of which timestamp has preference in a merge, but that sounds solvable. + +I made this a separate bug because it's a specific design proposal; I consider [[todo/does_not_preserve_timestamps]] a tracking bug/user story. + +proposal re [[/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/#comment-2ea94161228f0653917b91d4f999153f]]: File and symlink timestamps, after `git-annex-get` or `git-checkout`, are set to whatever's in the repo and then considered immutable. The user can of course change them with `touch`, but if the file is locked while that happens, that's considered a corruption like editing an object file and will be caught by `git-annex-fsck`. +"""]] From f96de421387c7dc291e3e0d78d23cb236f19f1e9 Mon Sep 17 00:00:00 2001 From: svw Date: Fri, 6 Apr 2018 06:51:36 +0000 Subject: [PATCH 2/2] --- ..._-___40__re__41__podcast__from_your_annex.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn diff --git a/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn new file mode 100644 index 0000000000..9e6d7654f5 --- /dev/null +++ b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn @@ -0,0 +1,15 @@ +Hi all, + +I've written a simple tool in Python to re-podcast from an annex: [recastex](https://github.com/stewart123579/recastex) + +Starting with the [downloading podcasts](https://git-annex.branchable.com/tips/downloading_podcasts/) page, I've got a number of podcasts on my laptop, but they were not really synced to my podcast app on my phone. Not a problem any longer. + +The app uses the metadata associated with *locally available* files to generate feeds for each of your "subscribed" podcasts - and collects anything else you have (like individual files) into a catch-all feed. + +It's designed with git-annex + limited network + privacy in mind separating the public internet queries from the things that can be done over git-annex. + +*(As the author of [git-annex-metadata-gui](https://git-annex.branchable.com/tips/a_gui_for_metadata_operations/) said...)* I hope these can be useful to someone other than myself. + + + +