Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2018-04-06 17:38:52 -04:00
commit 76f352a9a9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 30 additions and 0 deletions

View file

@ -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`.
"""]]

View file

@ -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.