diff options
| author |  Joey Hess <joey@kitenet.net> | 2014-05-29 15:23:05 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2014-05-29 15:23:05 -0400 |
| commit | 1f6cfecc972b121fa42ea80383183bbaccc2195a (patch) | |
| tree | 0a450c4226f5e05c2a3597a9f520376de281fffe /doc/todo | |
| parent | a95fb731cd117f35a6e0fce90d9eb35d0941e26e (diff) | |
remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were least edited before 2014.
Command line used:
for f in $(grep -l '\[\[done\]\]' *.mdwn); do if [ -z $(git log --since=2014 --pretty=oneline "$f") ]; then git rm $f; git rm -rf $(echo "$f" | sed 's/.mdwn$//'); fi; done
Diffstat (limited to 'doc/todo')
270 files changed, 0 insertions, 4403 deletions
diff --git a/doc/todo/Allow_syncing_only_selected_branches.mdwn b/doc/todo/Allow_syncing_only_selected_branches.mdwn deleted file mode 100644 index 78766e4df..000000000 --- a/doc/todo/Allow_syncing_only_selected_branches.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -It seems that currently, syncing will result in every branch winding -up everywhere within the network of git annex nodes. It would be great -if one could keep some branches purely local. - -The «fetch» part of «sync» seems to respect the fetch refspec in the -git config, but the push part seems to always push everything. - -> [[done]] diff --git a/doc/todo/Allow_syncing_only_selected_branches/comment_1_bb687b1a50d8a926abd16ada639140e1._comment b/doc/todo/Allow_syncing_only_selected_branches/comment_1_bb687b1a50d8a926abd16ada639140e1._comment deleted file mode 100644 index 00f18cf72..000000000 --- a/doc/todo/Allow_syncing_only_selected_branches/comment_1_bb687b1a50d8a926abd16ada639140e1._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 1" - date="2014-05-15T19:51:48Z" - content=""" -No, it does not: - -<pre> -push wren -[2014-05-15 15:50:33 JEST] call: git [\"--git-dir=/home/joey/lib/big/.git\",\"--work-tree=/home/joey/lib/big\",\"push\",\"wren\",\"+git-annex:synced/git-annex\",\"master:synced/master\"] -[2014-05-15 15:50:39 JEST] read: git [\"--git-dir=/home/joey/lib/big/.git\",\"--work-tree=/home/joey/lib/big\",\"push\",\"wren\",\"master\"] -</pre> - -That is the entirity of what's pushed: The git-annex branch, and the currently checked out branch. - -I don't see a bug here. -"""]] diff --git a/doc/todo/Allow_syncing_only_selected_branches/comment_2_46d27fe74b4adac2e740fa555f549459._comment b/doc/todo/Allow_syncing_only_selected_branches/comment_2_46d27fe74b4adac2e740fa555f549459._comment deleted file mode 100644 index 49b939f13..000000000 --- a/doc/todo/Allow_syncing_only_selected_branches/comment_2_46d27fe74b4adac2e740fa555f549459._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 2" - date="2014-05-16T08:40:47Z" - content=""" -Joey, thanks for clearing that up. In my test-case I only had two -branches, and I mistook it for pushing everything. Actually, what I -wanted to achieve was the following: - -Have a main repo M with branches A and A-downstream, and have a -downstream repo D with just A-downstream. What confused me was that -the main repo always pushed A to D. I suppose if I just have the two -branches, I would achieve the desired effect by not using «annex -sync», and instead just pushing the git-annex branch manually; would -that be the way to go? - -"""]] diff --git a/doc/todo/Build_for_Synology_DSM.mdwn b/doc/todo/Build_for_Synology_DSM.mdwn deleted file mode 100644 index 650500756..000000000 --- a/doc/todo/Build_for_Synology_DSM.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -It would be wonderful if a pre-built package would be available for Synology NAS. Basically, this is an ARM-based Linux. It has most of the required shell commands either out of the box or easily available (through ipkg). But I think it would be difficult to install the Haskell compiler and all the required modules, so it would probably be better to cross-compile targeting ARM. - -> [[done]]; the standalone armel tarball has now been tested working on -> Synology. --[[Joey]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_10_e351084d9a83db3fd6d9d983227a6410._comment b/doc/todo/Build_for_Synology_DSM/comment_10_e351084d9a83db3fd6d9d983227a6410._comment deleted file mode 100644 index b62a929d7..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_10_e351084d9a83db3fd6d9d983227a6410._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 10" - date="2013-06-02T17:23:43Z" - content=""" -I updated the C program to simplify it so it uses a static path for `_chrooter`. In the previous version, I suspect that one can play with symlinks and use it to get a root shell. So, if `_chrooter` is not installed in `/opt/bin` this file has to be edited too before compilation. -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_11_cc67a584f5c460a6fb63cf099c20e573._comment b/doc/todo/Build_for_Synology_DSM/comment_11_cc67a584f5c460a6fb63cf099c20e573._comment deleted file mode 100644 index 324fa8423..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_11_cc67a584f5c460a6fb63cf099c20e573._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 11" - date="2013-06-03T09:55:54Z" - content=""" -A last update and I stop spamming this thread: I've implemented access control and simplified customisation. All this has been moved to https://bitbucket.org/franckp/gasp - -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_12_94023593d294b9cf69090fcfd6ca0e5a._comment b/doc/todo/Build_for_Synology_DSM/comment_12_94023593d294b9cf69090fcfd6ca0e5a._comment deleted file mode 100644 index 39c243ec4..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_12_94023593d294b9cf69090fcfd6ca0e5a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlJEI45rGczFAnuM7gRSj4C6s9AS9yPZDc" - nickname="Kevin" - subject="SynoCommunity" - date="2013-06-26T18:12:39Z" - content=""" -Creating an installable git-annex package available via [SynoCommunity](http://www.synocommunity.com/) would be awesome. They have created [cross-compilation tools](https://github.com/SynoCommunity/spksrc) to help build the packages and integrate the start/stop scripts with the package manager. - -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_13_314255fd503d125b5aeae2f62acfd592._comment b/doc/todo/Build_for_Synology_DSM/comment_13_314255fd503d125b5aeae2f62acfd592._comment deleted file mode 100644 index 3c54a9271..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_13_314255fd503d125b5aeae2f62acfd592._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnrP-0DGtHDJbWSXeiyk0swNkK1aejoN3c" - nickname="sebastien" - subject="comment 13" - date="2013-08-06T12:18:35Z" - content=""" -I post an issue to github synocommunity for that, i hope somenone have some time to package this great features. -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment b/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment deleted file mode 100644 index c3edf99e2..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="lorenzo" - ip="84.75.27.69" - subject="Running Debian squeeze binaries on libc 2.5 based NAS" - date="2013-10-27T23:56:26Z" - content=""" -Following the suggestions in this page I tried to run the binaries that debian provides on my Lacie NetworkSpace which is another one of these NAS devices with old libc. After uploading the binaries and required libraries and using `LD_LIBRARY_PATH` to force the loader to use the version I uploaded of the libraries I was still having a segfault (similar to what Franck was experiencing) while running git-annex in a chroot was working. - -It turns out that it is possible to solve the problem without having to use chroot by not loading the binary directly but by substituting it with a script that calls the correct `ld-linux.so.3`. Assume you have uncompressed the files from the deb packages in `/opt/git-annex`. - -First create a directory `/opt/git-annex/usr/bin/git-annex.exec` and copy the executable `/opt/git-annex/usr/bin/git-annex` there. - -Then create script `/opt/git-annex/usr/bin/git-annex` with the following contents: - - #!/bin/bash - - PREFIX=/opt/git-annex - - export GCONV_PATH=$PREFIX/usr/lib/gconv - - exec $PREFIX/lib/ld-linux.so.3 --library-path $PREFIX/lib/:$PREFIX/usr/lib/ $PREFIX/usr/bin/git-annex.exec/git-annex \"$@\" - -The `GCONV_PATH` setting is important to prevent the app from failing with the message: - - git-annex.exec: mkTextEncoding: invalid argument (Invalid argument) - -The original executable is moved to a different directory instead of being simply renamed to make sure that `$0` is correct when the executable starts. The parameter for the linker `--library-path` is used instead of the environment variable `LD_LIBRARY_PATH` to make sure that the programs exec'ed by git-annex do not have the variable set. - -Some more info about the approach: [[http://www.novell.com/coolsolutions/feature/11775.html]] -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_15_c12f525ef4cbe42cdf20fec0d53c8d86._comment b/doc/todo/Build_for_Synology_DSM/comment_15_c12f525ef4cbe42cdf20fec0d53c8d86._comment deleted file mode 100644 index 007199f5b..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_15_c12f525ef4cbe42cdf20fec0d53c8d86._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.87" - subject="comment 15" - date="2013-12-16T05:55:29Z" - content=""" -Following the example of @lorenzo, I have made all the git-annex Linux standalone builds include glibc and shims to make the linker use it. - -Now that there's a [[forum/new_linux_arm_tarball_build]], it may *just work* on Synology. -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment b/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment deleted file mode 100644 index 074ba998c..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_1_4059016fa8da6af7a3eba8966821e8eb._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 1" - date="2013-05-24T15:55:42Z" - content=""" -There are already git-annex builds for arm available from eg, Debian. There's a good chance that, assuming you match up the arm variant (armel, armhf, etc) and that the NAS uses glibc and does not have too old a version, that the binary could just be copied in, possibly with some other libraries, and work. This is what's done for the existing Linux standalone builds. - -So, I look at this bug report as \"please add a standalone build for arm\", not as a request to support a specific NAS which I don't have ;) -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_2_8900c2985ab68b3b566c9f5d326471d6._comment b/doc/todo/Build_for_Synology_DSM/comment_2_8900c2985ab68b3b566c9f5d326471d6._comment deleted file mode 100644 index 40e6398f0..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_2_8900c2985ab68b3b566c9f5d326471d6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 2" - date="2013-05-24T21:31:44Z" - content=""" -I tried to run the binary from the Debian package, unfortunately, after installing tons of libraries, git-annex fails complaining that GLIBC is not recent enough. Perhaps a static build for ARM (armel) can solve the problem? Thanks again for your help! -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_3_f2b77368473d42b7f21e9d51d6415b58._comment b/doc/todo/Build_for_Synology_DSM/comment_3_f2b77368473d42b7f21e9d51d6415b58._comment deleted file mode 100644 index 651edacd7..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_3_f2b77368473d42b7f21e9d51d6415b58._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 3" - date="2013-05-25T04:42:22Z" - content=""" -Which Debian package? Different ones link to different libcs. - -(It's not really possible to statically link something with as many dependencies as git-annex on linux anymore, unfortunately.) -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_4_a55fea734044c270ceb10adf9c8d9a76._comment b/doc/todo/Build_for_Synology_DSM/comment_4_a55fea734044c270ceb10adf9c8d9a76._comment deleted file mode 100644 index 50ae82ca0..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_4_a55fea734044c270ceb10adf9c8d9a76._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 4" - date="2013-05-25T07:40:13Z" - content=""" -I've actually tried several ones: 4.20130521 on sid, 3.20120629~bpo60+2 on squeeze-backports, 3.20120629 on wheezy and jessie, plus a package for Ubuntu 11.02. All of them try to load GLIBC 2.6/2.7 while my system has 2.5 only... I'll try a different approach: install Debian in a chroot on the NAS and extract all the required files, including all libraries. -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_5_59865ada057c640ac29855c65cf45dd9._comment b/doc/todo/Build_for_Synology_DSM/comment_5_59865ada057c640ac29855c65cf45dd9._comment deleted file mode 100644 index 725025283..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_5_59865ada057c640ac29855c65cf45dd9._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 5" - date="2013-05-25T10:03:24Z" - content=""" -Unfortunately, chroot approach does not work either. While git-annex works fine when I'm in the chroot, it doesn't work any more outside. If I don't copy libc, I get a version error (just like before so this is normal): - - git-annex: /lib/libc.so.6: version `GLIBC_2.7' not found (required by /opt/share/git-annex/bin/git-annex) - git-annex: /lib/libc.so.6: version `GLIBC_2.6' not found (required by /opt/share/git-annex/bin/git-annex) - git-annex: /lib/libc.so.6: version `GLIBC_2.7' not found (required by /opt/share/git-annex/lib/libgmp.so.10) - -When I copy libc from the Debian chroot, then, it complains about libpthread: - - git-annex: relocation error: /lib/libpthread.so.0: symbol __default_rt_sa_restorer, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference - -If then I copy libpthread also, I get: - - Illegal instruction (core dumped) - -So, I'm stuck... :-( -I'll try to find a way using the version in the chroot instead of trying to export it to the host system... -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_6_6d860b1ad8816077b5fa596a71b12d5c._comment b/doc/todo/Build_for_Synology_DSM/comment_6_6d860b1ad8816077b5fa596a71b12d5c._comment deleted file mode 100644 index 417293db3..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_6_6d860b1ad8816077b5fa596a71b12d5c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" - nickname="Michael" - subject="bind mount" - date="2013-05-25T15:55:52Z" - content=""" -You could bind-mount (e.g. mount -o bind /data /chroot/data ) your main Synology fs into the chroot for git-annex to use. -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_7_19ef2d293ba3bc7ece443d7278371c3f._comment b/doc/todo/Build_for_Synology_DSM/comment_7_19ef2d293ba3bc7ece443d7278371c3f._comment deleted file mode 100644 index 47d092331..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_7_19ef2d293ba3bc7ece443d7278371c3f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 7" - date="2013-05-25T19:01:29Z" - content=""" -This is indeed what I'm doing. But I need to make a wrapper that will call the command in the chroot. Thanks for the tip anyway. :-) -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_8_609b7ad87dfbba49ec1f8c6fc2739ccd._comment b/doc/todo/Build_for_Synology_DSM/comment_8_609b7ad87dfbba49ec1f8c6fc2739ccd._comment deleted file mode 100644 index 8a3490956..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_8_609b7ad87dfbba49ec1f8c6fc2739ccd._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc" - nickname="Sören" - subject="comment 8" - date="2013-05-26T13:50:31Z" - content=""" -I have a Synology NAS too, so I thought I could try to run git-annex in a Debian chroot. -As it [turns out](http://forum.synology.com/wiki/index.php/What_kind_of_CPU_does_my_NAS_have), my model (DS213+) runs on a PowerPC CPU instead of ARM. Unfortunately, it isn't compatible with PPC in Debian either because it is a different PowerPC variant. -There is an unofficial Debian port called [powerpcspe](http://wiki.debian.org/PowerPCSPEPort), but ghc doesn't build there yet for [some reason](http://buildd.debian-ports.org/status/package.php?p=git-annex&suite=sid). - -Any chance that there will be a build for this architecture at some point in the future or should I better look for another NAS? ;-) -"""]] diff --git a/doc/todo/Build_for_Synology_DSM/comment_9_d94a73b9a07c5cadf191005f817fd59a._comment b/doc/todo/Build_for_Synology_DSM/comment_9_d94a73b9a07c5cadf191005f817fd59a._comment deleted file mode 100644 index c8b45fc60..000000000 --- a/doc/todo/Build_for_Synology_DSM/comment_9_d94a73b9a07c5cadf191005f817fd59a._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA" - nickname="Franck" - subject="comment 9" - date="2013-06-02T13:14:56Z" - content=""" -Hi, I finally succeeded! :-) - -Here are the main steps: - - 1. install `debian-chroot` on the NAS - 2. create an account `gitannex` in Debian - 3. configure git on this account (this is important otherwise git complains and fails) `git config --global user.email YOUR_EMAIL` and `git config --global user.name YOUR_NAME` - 4. install `gcc` on the NAS (using `ipkg`) - 5. download the files here: https://www.dropbox.com/sh/b7z68a730aj3mnm/95nFOzE1QP - 6. edit `_chrooter` to fit your settings (probably there is nothing to change if your Debian is freshly installed) - 7. run `make install`, everything goes to `/opt/bin`, if you change this, you should also edit line 17 in file `gasp` - 8. create an account `gitannex` on the NAS (doesn't need to be the same name as in Debian, but I feel it is easier) - 9. edit its `.ssh/authorized_keys` to prefix lines as follows `command=\"gasp\" THE_PUBLIC_KEY_AS_USUAL` - 10. it should work - 11. the repositories will be in the Debian account, but it's easy to symlink them in the NAS account if you wish - -The principle is as follows: `command=\"gasp\"` allows to launch `gasp` on SSH connexion instead of the original command given to `ssh`. This command is retrieved by `gasp` and prefixed with `chrooter-` (so, eg, running `ssh git` on the client results in running `chrooter-git` on the NAS). `chrooter-*` commands are symlinks to `chrooter`, this is a setuid root binary that launches `_chrooter`. (This intermediary binary is necessary because `_chrooter` is a script which cannot be setuid, and setuid is required for the chroot and identity change.) Finally, `_chrooter` starts the `debian-chroot` service, chroot to the target dir, changes identity and eventually launches the original command as if it was lauched directly by `gitannex` user in Debian. `_chrooter` and `gasp` are Python scripts, I did not use shell in order to avoid error-prone issues with spaces in arguments (that need to be passed around several times in the process). - -I'll try now to add command-line parameters to `gasp` in order to restrict the commands that can be run through SSH and the repositories allowed. - -Cheers, -Franck -"""]] diff --git a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp.mdwn b/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp.mdwn deleted file mode 100644 index e102606ca..000000000 --- a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Especially on Mac OSX (and Windows, and maybe Android), it would be great to be able to check in the webapp if an upgrade is available. A deeper integration with these OS would be even better: for example on Mac OSX, an icon on the status bar list available upgrades for some programs, including LibreOffice and others which are not installed by default. - -Also, it would be great to be able to download and install git-annex upgrades directly from the webapp. - -> comprehensively [[done]]; [[design/assistant/upgrading]] --[[Joey]] diff --git a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_1_c904182f6bff8b1a42070bbc038eb34e._comment b/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_1_c904182f6bff8b1a42070bbc038eb34e._comment deleted file mode 100644 index 750e3b83a..000000000 --- a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_1_c904182f6bff8b1a42070bbc038eb34e._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.246" - subject="comment 1" - date="2013-11-15T20:51:18Z" - content=""" -I have thought about doing this, especially if there is ever a security hole in git-annex. - -All it needs is a file containing the version number to be written along-side the git-annex build, and git-annex knowing if it was built as a standalone build, and should check that. - -As for actually performing the upgrade: - -* Easy on Linux -* Not sure on OSX.. Is it possible to use hdiutil attach to replace a dmg while a program contained in it is currently running? -* Probably impossible on Android, at least not without using double the space. Probably better to get git-annex into an app store. -* Doable on Windows, but would need git-annex to be distributed in a form that was not a installer.exe. -"""]] diff --git a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_2_ebe7a75ca291e7f749bfe9f46d10909d._comment b/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_2_ebe7a75ca291e7f749bfe9f46d10909d._comment deleted file mode 100644 index d06fe3961..000000000 --- a/doc/todo/Check_if_an_upgrade_is_available_in_the_webapp/comment_2_ebe7a75ca291e7f749bfe9f46d10909d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlzlNQbf6wBgv9j6-UqfpXcQyAYMF8S3t4" - nickname="Tim" - subject="comment 2" - date="2014-01-12T09:19:31Z" - content=""" -I am pretty sure you know about it, but have you seen https://f-droid.org/? I was rather surprised that git-annex isn't yet listed in that \"store\". -"""]] diff --git a/doc/todo/Enhancement:_git_annex_whereis_KEY.mdwn b/doc/todo/Enhancement:_git_annex_whereis_KEY.mdwn deleted file mode 100644 index 604bc5566..000000000 --- a/doc/todo/Enhancement:_git_annex_whereis_KEY.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -### Please describe the problem. - -Great work on git annex! One possible enhancement occured to me: It would be very useful though if the "whereis" command would support looking up the location of files by arbitrary keys. This way one could inspect the location of old content which is not currently checked-out in the tree. - -In a related vein, the "unused" command could report old filenames or describe the associated commits. Tracking old versions is a great feature of your git-based approach, but currently, tasks such as pruning selected content seem unwiedly. Though I might be missing existing solutions. You can easily "cut-off" the history by forcing a drop of all unused content. It would be cool if one could somehow "address" old versions by filename and commit/date and selectively drop just these. The same could go for the "whereis" command, where one could e.g. query which remote holds content which was stored under some filename at some specific date. - -Thanks Cheers! - -> I agree that it's useful to run whereis on a specific key. This can -> now be done using `git annex whereis --key KEY` -> [[done]] --[[Joey]] -> -> To report old filenames, unused would have to search back through the -> contents of symlinks in old versions of the repo, to find symlinks that -> referred to a key. The best way I know how to do that is `git log -S$KEY`, -> which is what unused suggests you use. But this is slow -- -> searching for a single key in one of my repos takes 25 seconds. -> That's why it doesn't do it for you. -> diff --git a/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_1_5d768ab0065e6ecbc8ea25d66c226758._comment b/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_1_5d768ab0065e6ecbc8ea25d66c226758._comment deleted file mode 100644 index eb60a25d3..000000000 --- a/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_1_5d768ab0065e6ecbc8ea25d66c226758._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 1" - date="2014-05-13T20:34:33Z" - content=""" -I suppose that makes sense. Is it more affordable to just retrieve the most recent filename? That would seem to be enough for many practical purposes. But I guess this would still possibly have to go through many revisions. I wonder if such a restricted search can be done by git though. Maybe using non-porcelain commands. -"""]] diff --git a/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_2_4189d9e91208a59381100613e254e731._comment b/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_2_4189d9e91208a59381100613e254e731._comment deleted file mode 100644 index e5645884e..000000000 --- a/doc/todo/Enhancement:_git_annex_whereis_KEY/comment_2_4189d9e91208a59381100613e254e731._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="134.147.14.84" - subject="comment 2" - date="2014-05-15T13:03:47Z" - content=""" -Okay, I suppose one way of doing a search that works like that would do a «git log --stat -S'KEY' $commit», starting with HEAD and then walking the parents. -"""]] diff --git a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp.mdwn b/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp.mdwn deleted file mode 100644 index e224215fc..000000000 --- a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -One Problem I am having is that I could never get the xmpp pairing to work so whenever I switch machines I have to manually run sync once on the command line to get the changes. Is it possible to have a sync now button of some sort that will trigger a sync on the repos? - -> moved from forum; [[done]] --[[Joey]] diff --git a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_1_0d5c90eb0e8fe61b82a19c5fea343613._comment b/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_1_0d5c90eb0e8fe61b82a19c5fea343613._comment deleted file mode 100644 index a5f631d50..000000000 --- a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_1_0d5c90eb0e8fe61b82a19c5fea343613._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnR6E5iUghMWdUGlbA9CCs8DKaoigMjJXw" - nickname="Efraim" - subject="comment 1" - date="2014-03-06T20:37:36Z" - content=""" -not quite a sync button, but when I want to force sync now I turn off and turn on sync for one of the repos from the webapp and then it syncs. -"""]] diff --git a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_2_196552002d70390e8b52b4af61dca903._comment b/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_2_196552002d70390e8b52b4af61dca903._comment deleted file mode 100644 index 41e05bf6e..000000000 --- a/doc/todo/Feature_Request:_Sync_Now_Button_in_Webapp/comment_2_196552002d70390e8b52b4af61dca903._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.146" - subject="comment 2" - date="2014-03-06T22:12:27Z" - content=""" -I've added a \"Sync now\" to the menu for each remote. So can be used to sync with an individual remote, or if picked from the menu for the local repository, it causes it to try to sync with every one if its remotes at once. -"""]] diff --git a/doc/todo/Limit_file_revision_history.mdwn b/doc/todo/Limit_file_revision_history.mdwn deleted file mode 100644 index 48b44dea2..000000000 --- a/doc/todo/Limit_file_revision_history.mdwn +++ /dev/null @@ -1,117 +0,0 @@ -Hi, I am assuming to use git-annex-assistant for two usecases, but I would like to ask about the options or planed roadmap for dropped/removed files from the repository. - -Usecases: - -1. sync working directory between laptop, home computer, work komputer -2. archive functionality for my photograps - -Both usecases have one common factor. Some files might become obsolate and -in long time frame nobody is interested to keep their revisions. Let's -assume photographs. Usuall workflow I take is to import all photograps to -filesystem, then assess (select) the good ones I want to keep and then -process them what ever way. - -Problem with git-annex(-assistant) I have is that it start to revision all -of the files at the time they are added to directory. This is welcome at -first but might be an issue if you are used to put 80% of the size of your -imported files to trash. - -I am aware of what git-annex is not. I have been reading documentation for -"git-annex drop" and "unused" options including forums. I do understand -that I am actually able to delete all revisions of the file if I will drop -it, remove it and if I will run git annex unused 1..###. (on all synced -repositories). - -I actually miss the option to have above process automated/replicated to the other synced repositories. - -I would formulate the 'use case' requirements for git-annex as: - -* command to drop an file including revisions from all annex repositories? - (for example like moving a file to /trash folder) that will schedulle - it's deletition) -* option to keep like max. 10 last revisions of the file? -* option to keep only previous revisions if younger than 6 months from now? - -Finally, how to specify a feature request for git-annex? - -> By moving it here ;-) --[[Joey]] - -> So, let's spec out a design. -> -> * Add preferred content terminal to configure whether a repository wants -> to hang on to unused content. Simply `unused`. -> (It cannot include a timestamp, because there's -> no way repos can agree on about when a key became unused.) **done** -> * In order to quickly match that terminal, the Annex monad will need -> to keep a Set of unused Keys. This should only be loaded on demand. -> **done** -> NB: There is some potential for a great many unused Keys to cause -> memory usage to balloon. -> * Client repositories will end their preferred content with -> `and (not unused)`. Transfer repositories too, because typically -> only client repos connect to them, and so otherwise unused files -> would build up there. Backup repos would want unused files. I -> think that archive repos would too. **done** -> * Make the assistant check for unused files periodically. Exactly -> how often may need to be tuned, but once per day seems reasonable -> for most repos. Note that the assistant could also notice on the -> fly when files are removed and mark their keys as unused if that was -> the last associated file. (Only currently possible in direct mode.) -> **done** -> * After scanning for unused files, it makes sense for the -> assistant to queue transfers of unused files to any remotes that -> do want them (eg, backup remotes). If the files can successfully be -> sent to a remote, that will lead to them being dropped locally as -> they're not wanted. -> * Add a git config setting like annex.expireunused=7d. This causes -> *deletion* of unused files after the specified time period if they are -> not able to be moved to a repo that wants them. -> (The default should be annex.expireunused=false.) -> * How to detect how long a file has been unused? We can't look at the -> time stamp of the object; we could use the mtime of the .map file, -> that that's direct mode only and may be replaced with a database -> later. Seems best to just keep a unused log file with timestamps. -> **done** -> * After the assistant scans for unused files, if annex.expireunused -> is not set, and there is some significant quantity of unused files -> (eg, more than 1000, or more than 1 gb, or more than the amount of -> remaining free disk space), -> it can pop up a webapp alert asking to configure it. **done** -> * Webapp interface to configure annex.expireunused. Reasonable values -> are no expiring, or any number of days. **done** -> -> [[done]] This does not cover every use case that was requested. -> But I don't see a cheap way to ensure it keeps eg the past 10 versions of -> a file. I guess that if you care about that, you leave -> annex.expireunused=false, and set up a backup repository where the unused -> files will be moved to. -> -> Note that since the assistant uses direct mode by default, old versions -> of modififed files are not guaranteed to be retained. But they very well -> might be. For example, if a file is replicated to 2 clients, and one -> client directly edits it, or deletes it, it loses the old version, -> but the other client will still be storing that old version. -> -> ## Stability analysis for unused in preferred content expressions -> -> This is tricky, because two repos that are otherwise entirely -> in sync may have differing opinons about whether a key is unused, -> depending on when each last scanned for unused keys. -> -> So, this preferred content terminal is *not stable*. -> It may be possible to write preferred content expressions -> that constantly moved such keys around without reaching a steady state. -> -> Example: -> -> A and B are clients directly connected, and both also connected -> to BACKUP. -> -> A deletes F. B syncs with A, and runs unused check; decides F -> is unused. B sends F to BACKUP. B will then think A doesn't want F, -> and will drop F from A. Next time A runs a full transfer scan, it will -> *not* find F (because the file was deleted!). So it won't get F back from -> BACKUP. -> -> So, it looks like the fact that unused files are not going to be -> looked for on the full transfer scan seems to make this work out ok. diff --git a/doc/todo/Option_for_browser_to_launch_webapp_with.mdwn b/doc/todo/Option_for_browser_to_launch_webapp_with.mdwn deleted file mode 100644 index dae601169..000000000 --- a/doc/todo/Option_for_browser_to_launch_webapp_with.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Firefox is my default browser, but as we all know, it doesn't load quickly. If I don't have Firefox running but I want to access the git-annex webapp, I'd rather launch the webapp in some small, quick browser like QupZilla than wait for Firefox to load. - -Could git-annex have a setting, maybe a "webapp --browser" option and/or a setting in the config file, to specify the browser to launch? - -> git-annex uses the standard `git config web.browser` if you set it. -> [[done]] -> --[[Joey]] diff --git a/doc/todo/Please_abort_build_if___34__make_test__34___fails.mdwn b/doc/todo/Please_abort_build_if___34__make_test__34___fails.mdwn deleted file mode 100644 index 592b5e077..000000000 --- a/doc/todo/Please_abort_build_if___34__make_test__34___fails.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -A failure during "make test" should be signalled to the caller by means of -a non-zero exit code. Without that signal, it's very hard to run the -regression test suite in an automated fashion. - -> git-annex used to have a Makefile that ignored make test exit status, -> but that was fixed in commit dab5bddc64ab4ad479a1104748c15d194e138847, -> in October 6th. [[done]] --[[Joey]] diff --git a/doc/todo/Please_add_support_for_monad-control_0.3.x.mdwn b/doc/todo/Please_add_support_for_monad-control_0.3.x.mdwn deleted file mode 100644 index f82224991..000000000 --- a/doc/todo/Please_add_support_for_monad-control_0.3.x.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Git-annex doesn't compile with the latest version of monad-control. Would it be hard to support that new version? - -> I have been waiting for it to land in Debian before trying to -> deal with its changes. -> -> There is now a branch in git called `new-monad-control` that will build -> with the new monad-control. --[[Joey]] - ->> Now merged to master. [[done]] --[[Joey]] diff --git a/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn b/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn deleted file mode 100644 index cbd01181f..000000000 --- a/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -Please provide a command that basically performs something like: - -git get --auto -for i in `git remote`; do git copy -to $i --auto; done - - -The use case is this: -I have a very large repo (300.000 files) in three places. Now I want the fastest possible way to ensure, that every file exists in annex.numcopies. This should scan every file one time and then get it or copy it to other repos as needed. Right now, I make one "git annex get --auto" in every repo, which is is a waste of time, since most of the files never change anyway! - -> Now `git annex sync --content` does effectivly just what the shown for -> loop does. [[done]] -> -> The only difference is that copy --auto proactively downloads otherwise -> unwanted files to satisfy numcopies, and sync --content does not. -> We need a [[preferred_content_numcopies_check]] to solve that. -> --[[Joey]] diff --git a/doc/todo/S3.mdwn b/doc/todo/S3.mdwn deleted file mode 100644 index 7e417336f..000000000 --- a/doc/todo/S3.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -Support Amazon S3 as a file storage backend. - -There's a haskell library that looks good. Not yet in Debian. - -Multiple ways of using S3 are possible. Currently implemented as -a special type of git remote. - -Before this can be close, I need to fix: - -## encryption - -TODO - -## unused checking - -One problem is `git annex unused`. Currently it only looks at the local -repository, not remotes. But if something is dropped from the local repo, -and you forget to drop it from S3, cruft can build up there. - -This could be fixed by adding a hook to list all keys present in a remote. -Then unused could scan remotes for keys, and if they were not used locally, -offer the possibility to drop them from the remote. - -[[done]] diff --git a/doc/todo/Sync_repo_names__63__.mdwn b/doc/todo/Sync_repo_names__63__.mdwn deleted file mode 100644 index d3bb59f04..000000000 --- a/doc/todo/Sync_repo_names__63__.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -It's very confusing to me that the same repo viewed from different client systems can have different names and descriptions. This implies that making changes to a remote repo from one system only affects how that system sees the repo, but it seems to affect how the entire git-annex "pair" or "network of repos" sees it. - -I think it would be good if the names and descriptions of repos were synced across clients. - -> The descriptions of repositories are synced. (They're stored in git-annex:uuid.log) -> -> git allows for the same repository to be referred to using as many different remote names as you want to set up. git-annex inherits this, -> and I can't see this changing; there are very good reasons for remotes to -> have this flexability. [[done]] -> --[[Joey]] diff --git a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn deleted file mode 100644 index 48c136b26..000000000 --- a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -This is just an idea, and I have no idea if it would work (that's why I'm asking): - -**Would it be possible to use ASICs made for Bitcoin mining inside git-annex to offload the hashing of files?** - -I got the idea, because I have two RaspberryPis here: - -- one runs my git-annex archive. It is really slow at hashing, so I resorted to using the WORM backend -- another one runs 2 old-ish ASIC miners. They are just barely "profitable" right now, so in a few months they will be obsolete - -Both devices to some kind of `SHA256`. I have a feeling this is either extremely easy or extremely complicated to do… :) - -> git-annex uses binaries such as `sha256sum` for hashing large files (large is -> currently hardcoded as bigger than 1MB). If you insert a binary with the same -> interface as `sha256sum` into your `$PATH`, git-annex will automatically use -> it. If you want to use ASIC hashing even for small files, you need to tweak -> `Backend/Hash.hs`. --[[HelmutGrohne]] - ->> [[done]] --[[Joey]] diff --git a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__/comment_1_a93805a8088402c6dc32d2b9785fcc7d._comment b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__/comment_1_a93805a8088402c6dc32d2b9785fcc7d._comment deleted file mode 100644 index 952978834..000000000 --- a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__/comment_1_a93805a8088402c6dc32d2b9785fcc7d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.172" - subject="comment 1" - date="2014-02-20T17:42:10Z" - content=""" -I feel that Helmut has the right approach to this general type of thing. - -I doubt that bitcoin ASICs feature a fast data transfer bus, because bitcoin is a pretty low-data-volume protocol. Additionally AIUI, bitcoin ASICs get their speed by hashing in parallel, which allows them to try many variations of a block at once. So they probably rely on most of the data remaining the same and only a small amount changing. So it's doubtful this would be a win. -"""]] diff --git a/doc/todo/Wishlist:_Import_youtube_playlists.mdwn b/doc/todo/Wishlist:_Import_youtube_playlists.mdwn deleted file mode 100644 index 4826d9d24..000000000 --- a/doc/todo/Wishlist:_Import_youtube_playlists.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Hi, - -it would be great if the importfeed command would be able to read feeds generated by youtube (like for playlists). The youtube playlist feed contains links to separate youtube video pages, which quvi handles just fine. Currently I use the following python script: - - #!/usr/bin/env python - import feedparser - import sys - d = feedparser.parse('http://gdata.youtube.com/feeds/api/playlists/%s' % sys.argv[1]) - for entry in d.entries: - print entry.link - -and then - - kasimon@pc:~/annex/YouTube/debconf13$ youtube-playlist-urls PLz8ZG1e9MPlzefklz1Gv79icjywTXycR- | xargs git annex addurl --fast - addurl Welcome_talk.webm ok - addurl Bits_from_the_DPL.webm ok - addurl Debian_Cosmology.webm ok - addurl Bits_from_the_DPL.webm ok - addurl Debian_Cosmology.webm ok - addurl Debian_on_Google_Compute_Engine.webm ok - ^C - -to create a backup of youtube media I'd like to keep. - -It would be great if this functionality could be integrated directly into git annex. - -Best -Karsten - -> [[done]] --[[Joey]] diff --git a/doc/todo/Wishlist:_Import_youtube_playlists/comment_1_4235cbbb0c6f9d83524c970c4588cb2e._comment b/doc/todo/Wishlist:_Import_youtube_playlists/comment_1_4235cbbb0c6f9d83524c970c4588cb2e._comment deleted file mode 100644 index 3e3c4be82..000000000 --- a/doc/todo/Wishlist:_Import_youtube_playlists/comment_1_4235cbbb0c6f9d83524c970c4588cb2e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 1" - date="2013-12-29T18:21:32Z" - content=""" -Ok, so importfeed looks for items in a feed with enclosures, but this feed is not a podcast feed. So it needs to look for some of the `<links>` -to find pages that quvi supports. (There might be other links that are not video pages, for all I know. Looks like `getItemLink` finds the right links and then I just need to filter through quvi. -"""]] diff --git a/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex.mdwn b/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex.mdwn deleted file mode 100644 index 996c03461..000000000 --- a/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -As per IRC - - 22:13:10 < RichiH> joeyh: btw, i have been pondering a `git annex import --lazy` or some such which basically goes through a directory and deletes everything i find in the annex it run from - 22:50:39 < joeyh> not sure of the use case - 23:41:06 < RichiH> joeyh: the use case is "i have important a ton of data into my annexes. now, i am going through the usual crud of cp -ax'ed, rsync'ed, and other random 'new disk, move stuff around and just put a full dump over there' file dumps and would like to delete everything that's annexed already" - 23:41:33 < RichiH> joeyh: that would allow me to spend time on dealing with the files which are not yet annexed - 23:41:54 < RichiH> instead of verifying file after file which has been imported already - 23:43:19 < joeyh> have you tried just running git annex import in a subdirectory and then deleting the dups? - 23:45:34 < joeyh> or in a separate branch for that matter, which you could then merge in, etc - 23:54:08 < joeyh> Thinking anout it some more, it would need to scan the whole work tree to see what keys were there, and populate a lookup table. I prefer to avoid things that need git-annex to do such a large scan and use arbitrary amounts of memory. - 00:58:11 < RichiH> joeyh: that would force everything into the annex, though - 00:58:20 < RichiH> a plain import, that is - 00:58:53 < RichiH> in a usual data dump directory, there's tons of stuff i will never import - 00:59:00 < RichiH> i want to delete large portions of it - 00:59:32 < RichiH> but getting rid of duplicates first allows me to spend my time focused on stuff humans are good at: deciding - 00:59:53 < RichiH> whereas the computer can focus on stuff it's good at: mindless comparision of bits - 01:00:15 < RichiH> joeyh: as you're saying this is complex, maybe i need to rephrase - 01:01:40 < RichiH> what i envision is git annex import --foo to 1) decide what hashing algorithm should be used for this file 2) hash that file 3) look into the annex if that hash is annexed 3a) optionally verify numcopies within the annex 4) delete the file in the source directory - 01:01:47 < RichiH> and then move on to the next file - 01:02:00 < RichiH> if the hash does not exist in the annex, leave it alone - 01:02:50 < RichiH> if the hash exists in annex, but numcopies is not fulfilled, just import it as a normal import would - 01:03:50 < RichiH> that sounds quite easy, to me; in fact i will prolly script it if you decide not to implement it - 01:04:07 < RichiH> but i think it's useful for a _lot_ of people who migrate tons of data into annexes - 01:04:31 < RichiH> thus i would rather see this upstream and not hacked locally - -The only failure mode I see in the above is "file has been dropped elsewhere, numcopies not fulfilled, but that info is not synched to the local repo, yet" -- This could be worked around by always importing the data. - -> [[done]] as `git annex import --deduplicate`. -> --[[Joey]] diff --git a/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex/comment_1_0cc16eb17151309113cec6d1cccf203d._comment b/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex/comment_1_0cc16eb17151309113cec6d1cccf203d._comment deleted file mode 100644 index 0b4e22e7c..000000000 --- a/doc/todo/__96__git_annex_import_--lazy__96___--_Delete_everything_that__39__s_in_the_source_directory_and_also_in_the_target_annex/comment_1_0cc16eb17151309113cec6d1cccf203d._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2013-08-06T14:22:03Z" - content=""" -To expand a bit on the use case: - -I have several migration directories which I simply moved to new systems or disks with the help of `cp -ax` or `rsync`. -As I don't _need_ the data per se and merely want to hold on to it in case I ever happen to need it again and as disk space is laughably cheap, I have a lot of duplicates. -While I can at least detect bit flips with the help of checksum lists, cleaning those duplicates of duplicated duplicates is quite some effort. -To make things worse, photos, music, videos, letter and whatnot are thrown into the same container directories. - -All in all, getting data out of those data dumps and into a clean structure is quite an effort. -`git annex import --lazy` would help with this effort as I could start with the first directory, sort stuff by hand, and annex it. -As soon as data lives in any of my annexes, I could simply run `git annex import --lazy` to get rid of all duplicates while retaining the unannexed files. -Iterating through this process a few times, I will be left with clean annexes on the one hand and stuff I can simply delete on the other hand. - -I could script all this by hand on my own machine, but I am _certain_ that others would find easy, integrated, and unit tested support for whittling down data dumps over time useful. -"""]] diff --git a/doc/todo/__96__git_annex_status__47__version__96___should_print_the_local_OS.mdwn b/doc/todo/__96__git_annex_status__47__version__96___should_print_the_local_OS.mdwn deleted file mode 100644 index 9c2afecb4..000000000 --- a/doc/todo/__96__git_annex_status__47__version__96___should_print_the_local_OS.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -That would make assessing weird reports like [[bugs/Should_UUID__39__s_for_Remotes_be_case_sensitive__63__/]] easier and quicker. - -> No, if people want to file a bug report, it's up to them to tell me -> relevant details about their OS. I'm not going down the rathole -> of making git-annex muck about trying to gather such information. -> [[done]] --[[Joey]] diff --git a/doc/todo/__96__git_annex_sync_--auto__96___or___96__git_annex_auto__96___--_synchronize_symlinks__44___tracking_info__44___and_actual_data.mdwn b/doc/todo/__96__git_annex_sync_--auto__96___or___96__git_annex_auto__96___--_synchronize_symlinks__44___tracking_info__44___and_actual_data.mdwn deleted file mode 100644 index ae0894955..000000000 --- a/doc/todo/__96__git_annex_sync_--auto__96___or___96__git_annex_auto__96___--_synchronize_symlinks__44___tracking_info__44___and_actual_data.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -As per DebConf13: Introduce a one-shot command to synchronize everything, -including data, with the other remotes. - -Especially useful for the debconf annex. - -> [[done]]; `git annex sync --content` --[[Joey]] diff --git a/doc/todo/add_--exclude_option_to_git_annex_find.mdwn b/doc/todo/add_--exclude_option_to_git_annex_find.mdwn deleted file mode 100644 index a797e97f5..000000000 --- a/doc/todo/add_--exclude_option_to_git_annex_find.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Seems pretty self-explanatory. - -> This was already implemented, the --exclude option can be used -> for find as well as most any other subcommand. --[[Joey]] [[done]] diff --git a/doc/todo/add_-all_option.mdwn b/doc/todo/add_-all_option.mdwn deleted file mode 100644 index 2f25759c2..000000000 --- a/doc/todo/add_-all_option.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -`--all` would make git-annex operate on either every key with content -present (or in some cases like `get` and `copy --from` on -every keys with content not present). - -This would be useful when a repository has a history with deleted files -whose content you want to keep (so you're not using `dropunused`). -Or when you have a lot of branches and just want to be able to fsck -every file referenced in any branch (or indeed, any file referenced in any -ref). It could also be useful (or even a -good default) in a bare repository. - -A problem with the idea is that `.gitattributes` values for keys not -currently in the tree would not be available (without horrific anounts of -grubbing thru history to find where/when the key used to exist). So -`numcopies` set via `.gitattributes` would not work. This would be a -particular problem for `drop` and for `--auto`. - ---[[Joey]] - -> [[done]]. The .gitattributes problem was solved simply by not -> supporting `drop --all`. `--auto` also cannot be mixed with --all for -> similar reasons. --[[Joey]] diff --git a/doc/todo/add_a_git_backend.mdwn b/doc/todo/add_a_git_backend.mdwn deleted file mode 100644 index 2b224710e..000000000 --- a/doc/todo/add_a_git_backend.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -There should be a backend where the file content is stored.. in a git -repository! - -This way, you know your annexed content is safe & versioned, but you only -have to deal with the pain of git with large files in one place, and can -use all of git-annex's features everywhere else. - -> Speaking as a future user, do very, very much want. -- RichiH - ->> Might also be interesting to use `bup` in the git backend, to work ->> around git's big file issues there. So git-annex would pull data out ->> of the git backend using bup. --[[Joey]] - ->>> Very much so. Generally speaking, having one or more versioned storage back-ends with current data in the local annexes sounds incredibly useful. Still being able to get at old data in via the back-end and/or making offline backups of the full history are excellent use cases. -- RichiH - -[[done]], the bup special remote type is written! --[[Joey]] - -> Yay! -- RichiH diff --git a/doc/todo/add_an_icon_for_the_.desktop_file.mdwn b/doc/todo/add_an_icon_for_the_.desktop_file.mdwn deleted file mode 100644 index 56428ff4b..000000000 --- a/doc/todo/add_an_icon_for_the_.desktop_file.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -Maybe add the icon /usr/share/doc/git-annex/html/logo.svg to the .desktp file. - -> [[done]] long ago.. --[[Joey]] diff --git a/doc/todo/add_metadata_to_annexed_files.mdwn b/doc/todo/add_metadata_to_annexed_files.mdwn deleted file mode 100644 index 3d81677cb..000000000 --- a/doc/todo/add_metadata_to_annexed_files.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -I would like to attach metadata to annexed files (objects) without -cluttering the workdir with files containing this metadata. A common use -case would be to add titles to my photo collection that could than end up -in a generated photo album. - -Depending on the implementation it might also be possible to use the metadata facility for a threaded commenting system. - -The first question is whether the metadata is attached to the objects and -thus shared by all paths pointing to the same data object or to paths in -the worktree. I've no preference here at this point. - -> This is [[done]]; see [[design/metadata]]. -> The metadata is attached to objects, not to files. -> --[[Joey]] diff --git a/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment b/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment deleted file mode 100644 index 8460300a7..000000000 --- a/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.63" - subject="comment 1" - date="2013-08-24T19:58:54Z" - content=""" -I don't know if git-annex is the right vehicle to fix this. It seems that a more generic fix that would work in non-git-annex repos would be better. - -I can answer your question though: The metadata such as urls and locations that git-annex stores in the git-annex branch is attached to objects, and not to work tree paths. -"""]] diff --git a/doc/todo/assistant_git_sync_laddering.mdwn b/doc/todo/assistant_git_sync_laddering.mdwn deleted file mode 100644 index 7dbc6480a..000000000 --- a/doc/todo/assistant_git_sync_laddering.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -When the [[design/assistant]] is running on a pair of remotes, I've seen -them get out of sync, such that every pull and merge results in a conflict, -that then has to be auto-resolved. - -This seems similar to the laddering problem described in this old bug: -[[bugs/making_annex-merge_try_a_fast-forward]] - ---[[Joey]] - -Think I've fixed this. [[done]] --[[Joey]] diff --git a/doc/todo/assistant_smarter_archive_directory_handling.mdwn b/doc/todo/assistant_smarter_archive_directory_handling.mdwn deleted file mode 100644 index fa5a3e4fc..000000000 --- a/doc/todo/assistant_smarter_archive_directory_handling.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -Client repos do not want files in archive directories. This can turn -out to be confusing to users who are using archive directories for their -own purposes and not aware of this special case in the assistant. It can -seem like the assistant is failing to sync their files. - -I thought, first, that it should have a checkbox to enable the archive -directory behavior. - -However, I think I have a better idea. Change the preferred content -expression for clients, so they want files in archive directories, *until* -those files land in an archive. - -This way, only users who set up an archive repo get this behavior. And they -asked for it by setting up that repo! - -Also, the new behavior will mean that files in archive directories still -propigate around to clients. Consider this topology: - - client A ---- client B ---- archive - -If a file is created in client A, and moved to an archive directory before -it syncs to B, it will never get to the archive, and will continue wasting -space on A. With the new behavior, A and B serve as effectively, transfer -repositories for archived content. - -Something vaguely like this should work as the preferred content -expression for the clients: - - exclude=archive/* or (include=archive/* and (not (copies=archive:1 or copies=smallarchive:1))) - -> [[done]] --[[Joey]] diff --git a/doc/todo/assistant_threaded_runtime.mdwn b/doc/todo/assistant_threaded_runtime.mdwn deleted file mode 100644 index 03ba66acf..000000000 --- a/doc/todo/assistant_threaded_runtime.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -The [[design/assistant]] would be better if git-annex used ghc's threaded -runtime (`ghc -threaded`). - -Currently, whenever the assistant code runs some external command, all -threads are blocked waiting for it to finish. - -For transfers, the assistant works around this problem by forking separate -upload processes, and not waiting on them until it sees an indication that -they have finished the transfer. While this works, it's messy.. threaded -would be better. - -When pulling, pushing, and merging, the assistant runs external git -commands, and this does block all other threads. The threaded runtime would -really help here. - -[[done]]; the assistant now builds with the threaded runtime. -Some work still remains to run certian long-running external git commands -in their own threads to prevent them blocking things, but that is easy to -do, now. --[[Joey]] - ---- - -Currently, git-annex seems unstable when built with the threaded runtime. -The test suite tends to hang when testing add. `git-annex` occasionally -hangs, apparently in a futex lock. This is not the assistant hanging, and -git-annex does not otherwise use threads, so this is surprising. --[[Joey]] - -> I've spent a lot of time debugging this, and trying to fix it, in the -> "threaded" branch. There are still deadlocks. --[[Joey]] - ->> Fixed, by switching from `System.Cmd.Utils` to `System.Process` ->> --[[Joey]] - ---- - -It would be possible to not use the threaded runtime. Instead, we could -have a child process pool, with associated continuations to run after a -child process finishes. Then periodically do a nonblocking waitpid on each -process in the pool in turn (waiting for any child could break anything not -using the pool!). This is probably a last resort... diff --git a/doc/todo/auto_remotes.mdwn b/doc/todo/auto_remotes.mdwn deleted file mode 100644 index 715dea720..000000000 --- a/doc/todo/auto_remotes.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -It should be possible for clones to learn about how to contact -each other without remotes needing to always be explicitly set -up. Say that `.git-annex/remote.log` is maintained by git-annex -to contain: - - UUID hostname URI - -The URI comes from configured remotes and maybe from -`file://$(pwd)`, or even `ssh://$(hostname -f)` -for the current repo. This format will merge without -conflicts or data loss. - -Then when content is belived to be in a UUID, and no -configured remote has it, the remote.log can be consulted and -URIs that look likely tried. (file:// ones if the hostname -is the same (or maybe always -- a removable drive might tend -to be mounted at the same location on different hosts), -otherwise ssh:// ones.) - -Question: When should git-annex update the remote.log? -(If not just on init.) Whenever it reads in a repo's remotes? - -> This sounds useful and the log should be updated every time any remote is being accessed. A counter or timestamp (yes, distributed times may be wrong/different) could be used to auto-prune old entries via a global and per-remote config setting. -- RichiH - ---- - -I no longer think I'd use this myself, I find that my repositories quickly -grow the paths I actually use, somewhat organically. Unofficial paths -across university quads come to mind. [[done]] --[[Joey]] diff --git a/doc/todo/auto_remotes/discussion.mdwn b/doc/todo/auto_remotes/discussion.mdwn deleted file mode 100644 index b9e1522a8..000000000 --- a/doc/todo/auto_remotes/discussion.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Remotes log should probably be stored in ".git/annex/remote.log" -instead of ".git-annex/remote.log" to prevent leaking credentials. - -> The idea is to distribute the info between repositories, which is -> why it'd go in `.git-annex`. Of course that does mean that repository -> location information would be included, and if that'd not desirable -> this feature would need to be turned off. --[[Joey]] diff --git a/doc/todo/automatic_bookkeeping_watch_command.mdwn b/doc/todo/automatic_bookkeeping_watch_command.mdwn deleted file mode 100644 index 28b02aff2..000000000 --- a/doc/todo/automatic_bookkeeping_watch_command.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -A "git annex watch" command would help make git-annex usable by users who -don't know how to use git, or don't want to bother typing the git commands. -It would run, in the background, watching via inotify for changes, and -automatically annexing new files, etc. - -The blue sky goal would be something automated like dropbox, except fully -distributed. All files put into the repository would propagate out -to all the other clones of it, as network links allow. Note that while -dropbox allows modifying files, git-annex freezes them upon creation, -so this would not be 100% equivalent to dropbox. --[[Joey]] - -This is a big project with its own [[design pages|design/assistant]]. - -> [[done]].. at least, we have a watch command an an assistant, which -> is still being developed. --[[Joey]] diff --git a/doc/todo/avoid_unnecessary_union_merges.mdwn b/doc/todo/avoid_unnecessary_union_merges.mdwn deleted file mode 100644 index 5cd4b6437..000000000 --- a/doc/todo/avoid_unnecessary_union_merges.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -Some commands cause a union merge unnecessarily. For example, `git annex add` -modifies the location log, which first requires reading the current log (if -any), which triggers a merge. - -Would be good to avoid these unnecessary union merges. First because it's -faster and second because it avoids a possible delay when a user might -ctrl-c and leave the repo in an inconsistent state. In the case of an add, -the file will be in the annex, but no location log will exist for it (fsck -fixes that). - -It may be that all that's needed is to modify Annex.Branch.change -to read the current value, without merging. Then commands like `get`, that -query the branch, will still cause merges, and commands like `add` that -only modify it, will not. Note that for a command like `get`, the merge -occurs before it has done anything, so ctrl-c should not be a problem -there. - -This is a delicate change, I need to take care.. --[[Joey]] - -> [[done]] (assuming I didn't miss any cases where this is not safe!) --[[Joey]] diff --git a/doc/todo/backendSHA1.mdwn b/doc/todo/backendSHA1.mdwn deleted file mode 100644 index 8c16b75ad..000000000 --- a/doc/todo/backendSHA1.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -This backend is not finished. - -In particular, while files can be added using it, git-annex will not notice -when their content changes, and will not create a new key for the new sha1 -of the net content. - -[[done]]; use unlock subcommand and commit changes with git diff --git a/doc/todo/branching.mdwn b/doc/todo/branching.mdwn deleted file mode 100644 index f65849584..000000000 --- a/doc/todo/branching.mdwn +++ /dev/null @@ -1,159 +0,0 @@ -[[done]] !!! - -The use of `.git-annex` to store logs means that if a repo has branches -and the user switched between them, git-annex will see different logs in -the different branches, and so may miss info about what remotes have which -files (though it can re-learn). - -An alternative would be to store the log data directly in the git repo -as `pristine-tar` does. Problem with that approach is that git won't merge -conflicting changes to log files if they are not in the currently checked -out branch. - -It would be possible to use a branch with a tree like this, to avoid -conflicts: - -key/uuid/time/status - -As long as new files are only added, and old timestamped files deleted, -there would be no conflicts. - -A related problem though is the size of the tree objects git needs to -commit. Having the logs in a separate branch doesn't help with that. -As more keys are added, the tree object size will increase, and git will -take longer and longer to commit, and use more space. One way to deal with -this is simply by splitting the logs among subdirectories. Git then can -reuse trees for most directories. (Check: Does it still have to build -dup trees in memory?) - -Another approach would be to have git-annex *delete* old logs. Keep logs -for the currently available files, or something like that. If other log -info is needed, look back through history to find the first occurance of a -log. Maybe even look at other branches -- so if the logs were on master, -a new empty branch could be made and git-annex would still know where to -get keys in that branch. - -Would have to be careful about conflicts when deleting and bringing back -files with the same name. And would need to avoid expensive searching thru -all history to try to find an old log file. - -## fleshed out proposal - -Let's use one branch per uuid, named git-annex/$UUID. - -- I came to realize this would be a good idea when thinking about how - to upgrade. Each individual annex will be upgraded independantly, - so each will want to make a branch, and if the branches aren't distinct, - they will merge conflict for sure. -- TODO: What will need to be done to git to make it push/pull these new - branches? -- A given repo only ever writes to its UUID branch. So no conflicts. - - **problem**: git annex move needs to update log info for other repos! - (possibly solvable by having git-annex-shell update the log info - when content is moved using it) -- (BTW, UUIDs probably don't compress well, and this reduces the bloat of having - them repeated lots of times in the tree.) -- Per UUID branches mean that if it wants to find a file's location - among configured remotes, it can examine only their branches, if - desired. -- It's important that the per-repo branches propigate beyond immediate - remotes. If there is a central bare repo, that means push --all. Without - one, it means that when repo B pulls from A, and then C pulls from B, - C needs to get A's branch -- which means that B should have a tracking - branch for A's branch. - -In the branch, only one file is needed. Call it locationlog. git-annex -can cache location log changes and write them all to locationlog in -a single git operation on shutdown. - -- TODO: what if it's ctrl-c'd with changes pending? Perhaps it should - collect them to .git/annex/locationlog, and inject that file on shutdown? -- This will be less overhead than the current staging of all the log files. - -The log is not appended to, so in git we have a series of commits each of -which replaces the log's entire contens. - -To find locations of a key, all (or all relevant) branches need to be -examined, looking backward through the history of each until a log -with a indication of the presense/absense of the key is found. - -- This will be less expensive for files that have recently been added - or transfered. -- It could get pretty slow when digging deeper. -- Only 3 places in git-annex will be affected by any slowdown: move --from, - get and drop. (Update: Now also unused, whereis, fsck) - -## alternate - -As above, but use a single git-annex branch, and keep the per-UUID -info in their own log files. Hope that git can auto-merge as long as -each observing repo only writes to its own files. (Well, it can, but for -non-fast-forward merges, the git-annex branch would need to be checked out, -which is problimatic.) - -Use filenames like: - - <observing uuid>/<location uuid> - -That allows one repo to record another's state when doing a -`move`. - -## outside the box approach - -If the problem is limited to only that the `.git-annex/` files make -branching difficult (and not to the related problem that commits to them -and having them in the tree are sorta annoying), then a simple approach -would be to have git-annex look in other branches for location log info -too. - -The problem would then be that any locationlog lookup would need to look in -all other branches (any branch could have more current info after all), -which could get expensive. - -## way outside the box approach - -Another approach I have been mulling over is keeping the log file -branch checked out in .git/annex/logs/ -- this would be a checkout of a git -repository inside a git repository, using "git fake bare" techniques. This -would solve the merge problem, since git auto merge could be used. It would -still mean all the log files are on-disk, which annoys some. It would -require some tighter integration with git, so that after a pull, the log -repo is updated with the data pulled. --[[Joey]] - -> Seems I can't use git fake bare exactly. Instead, the best option -> seems to be `git clone --shared` to make a clone that uses -> `.git/annex/logs/.git` to hold its index etc, but (mostly) uses -> objects from the main repo. There would be some bloat, -> as commits to the logs made in there would not be shared with the main -> repo. Using `GIT_OBJECT_DIRECTORY` might be a way to avoid that bloat. - -## notes - -Another approach could be to use git-notes. It supports merging branches -of notes, with union merge strategy (a hook would have to do this after -a pull, it's not done automatically). - -Problem: Notes are usually attached to git -objects, and there are no git objects corresponding to git-annex keys. - -Problem: Notes are not normally copied when cloning. - ------- - -## elminating the merge problem - -Most of the above options are complicated by the problem of how to merge -changes from remotes. It should be possible to deal with the merge -problem generically. Something like this: - -* We have a local branch `B`. -* For remotes, there are also `origin/B`, `otherremote/B`, etc. -* To merge two branches `B` and `foo/B`, construct a merge commit that - makes each file have all lines that were in either version of the file, - with duplicates removed (probably). Do this without checking out a tree. - -- now implemented as git-union-merge -* As a `post-merge` hook, merge `*/B` into `B`. This will ensure `B` - is always up-to-date after a pull from a remote. -* When pushing to a remote, nothing need to be done, except ensure - `B` is either successfully pushed, or the push fails (and a pull needs to - be done to get the remote's changes merged into `B`). diff --git a/doc/todo/checkout.mdwn b/doc/todo/checkout.mdwn deleted file mode 100644 index 50da2d62e..000000000 --- a/doc/todo/checkout.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -The checkout subcommand replaces the symlink that normally points at a -file's content, with a copy of the file. Once you've checked a file out, -you can edit it, and `git commit` it. On commit, git-annex will detect -if the file has been changed, and if it has, `add` its content to the -annex. - -> Internally, this will need to store the original symlink to the file, in -> `.git/annex/checkedout/$filename`. -> -> * git-annex uncheckout moves that back -> * git-annex pre-commit hook checks each file being committed to see if -> it has a symlink there, and if so, removes the symlink and adds the new -> content to the annex. -> -> And it seems the file content should be copied, not moved or hard linked: -> -> * Makes sure other annexes can find it if transferring it from -> this annex. -> * Ensures it's always available for uncheckout. -> * Avoids the last copy of a file's content being lost when -> the checked out file is modified. - -[[done]] diff --git a/doc/todo/direct_mode_guard.mdwn b/doc/todo/direct_mode_guard.mdwn deleted file mode 100644 index bb7f90897..000000000 --- a/doc/todo/direct_mode_guard.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -Currently [[/direct_mode]] allows the user to point many normally safe -git commands at his foot and pull the trigger. At LCA2013, a git-annex -user suggested modifying direct mode to make this impossible. - -One way to do it would be to move the .git directory. Instead, make there -be a .git-annex directory in direct mode repositories. git-annex would know -how to use it, and would be extended to support all known safe git -commands, passing parameters through, and in some cases verifying them. - -So, for example, `git annex commit` would run `git commit --git-dir=.git-annex` - -However, `git annex commit -a` would refuse to run, or even do something -intelligent that does not involve staging every direct mode file. - ----- - -One source of problems here is that there is some overlap between git-annex -and git commands. Ie, `git annex add` cannot be a passthrough for `git -add`. The git wrapper could instead be another program, or it could be -something like `git annex git add` - ---[[Joey]] - ----- - -Or, no git wrapper could be provided. Limit the commands to only git-annex -commands. This should be all that is needed to manage a direct mode -repository simply, and if the user is doing something complicated that -needs git access, they can set `GIT_DIR=.git-annex` and be careful not to -shoot off their foot. (Or can just switch to indirect mode!) - -This wins on simplicity, and if it's the wrong choice a git wrapper -can be added later. --[[Joey]] - ---- - -Implementation: Pretty simple really. Already did the hard lifting to -support `GIT_DIR`, so only need to override the default git directory -in direct mode when that's not set to `.git-annex`. - -A few things hardcode ".git", including Assistant.Threads.Watcher.ignored -and `Seek.withPathContents`, and parts of `Git.Construct`. - ---- - -Transition: git-annex should detect when it's in a direct mode repository -with a .git directory and no .git-annex directory, and transparently -do the move to transition to the new scheme. (And remember that `git annex -indirect` needs to move it back.) - -# alternative approach: move index - -Rather than moving .git, maybe move .git/index? - -This would cause git to think that all files in the tree were deleted. -So git commit -a would make a commit that removes them from git history. -But, the files in the work tree are not touched by this. - -Also, git checkout, git merge, and other things that manipulate the work -tree refuse to do anything if they'd change a file that they think is -untracked. - -Hmm, this does't solve the user accidentially running git add on an annexed -file; the whole file still gets added. - -# alternative approach: fake bare repo - -Set core.bare to true. This prevents all work tree operations, -so prevents any foot shooting. It still lets the user run commands like -git log, even on files in the tree, and git fetch, and push, and git -config, etc. - -Even better, it integrates with other tools, like `mr`, so they know -it's a git repo. - -This seems really promising. But of course, git-annex has its own set of -behaviors in a bare repo, so will need to recognise that this repo is not -really bare, and avoid them. - -> [[done]]!! --[[Joey]] - -(Git may also have some bare repo behaviors that are unwanted. One example -is that git allows pushes to the current branch in a bare repo, -even when `receive.denyCurrentBranch` is set.) - -> This is indeed a problem. Indeed, `git annex sync` successfully -> pushes changes to the master branch of a fake bare direct mode repo. -> -> And then, syncing in the repo that was pushed to causes the changes -> that were pushed to the master branch to get reverted! This happens -> because sync commits; commit sees that files are staged in index -> differing from the (pushed) master, and commits the "changes" -> which revert it. -> -> Could fix this using an update hook, to reject the updated of the master -> branch. However, won't work on crippled filesystems! (No +x bit) -> -> Could make git annex sync detect this. It could reset the master -> branch to the last one committed, before committing. Seems very racy -> and hard to get right! -> -> Could make direct mode operate on a different branch, like -> `annex/direct/master` rather than `master`. Avoid pushing to that -> branch (`git annex sync` can map back from it to `master` and push there -> instead). A bit clumsy, but works. diff --git a/doc/todo/direct_mode_guard/comment_1_431b6e1577bbd30b07dce9002a8fe1a2._comment b/doc/todo/direct_mode_guard/comment_1_431b6e1577bbd30b07dce9002a8fe1a2._comment deleted file mode 100644 index 01cddc8a3..000000000 --- a/doc/todo/direct_mode_guard/comment_1_431b6e1577bbd30b07dce9002a8fe1a2._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawn-KDr_Z4CMkjS0v_TxQ08SzAB5ecHG3K0" - nickname="Glen" - subject="This sounds good" - date="2013-06-25T10:30:07Z" - content=""" -I think we might have been talking about this feature.. Seems like a good idea to me. - -Glen -"""]] diff --git a/doc/todo/direct_mode_guard/comment_2_85bdb9dc601b87bd7c77150d7b0a5cde._comment b/doc/todo/direct_mode_guard/comment_2_85bdb9dc601b87bd7c77150d7b0a5cde._comment deleted file mode 100644 index 7cf37a917..000000000 --- a/doc/todo/direct_mode_guard/comment_2_85bdb9dc601b87bd7c77150d7b0a5cde._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo" - nickname="Georg" - subject="comment 2" - date="2013-09-20T11:29:04Z" - content=""" -Maybe make a git sub-namespace of commands. Yeah, I know, something like git annex git-add sounds a bit on the verbose side, but it would allow access to possibly all git commands regardless of name clashes. -"""]] diff --git a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__.mdwn b/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__.mdwn deleted file mode 100644 index 09123cb4c..000000000 --- a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -I've an external USB hard disc attached to my (fritzbox) router that is only accessible through SMB/CIFS. I'd like have all my annexed files on this drive in kind of direct-mode so that I can also access the files without git-annex. - -I tried to put a direct-mode repo on the drive but this is painfully slow. The git-annex process than runs on my desktop and accesses the repo over SMB over the slow fritzbox over USB. - -I'd wish that git-annex could be told to just use a (mounted) folder as a direct-mode remote. - -> [[done]]; dup. --[[Joey]] diff --git a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_1_5ed9a2336b432b842c1805add6d96509._comment b/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_1_5ed9a2336b432b842c1805add6d96509._comment deleted file mode 100644 index bff1b2fcd..000000000 --- a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_1_5ed9a2336b432b842c1805add6d96509._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.64" - subject="comment 1" - date="2013-11-23T19:03:58Z" - content=""" -It's not clear to me what you are requesting here. - -You seem to say that running git-annex inside a mountpoint is slow. Ok. So, what possible changes to git-annex could make it fast, given that the bottleneck is the SMB/USB? -"""]] diff --git a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_2_e6ba58c5c31ba23a4575f1189689946f._comment b/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_2_e6ba58c5c31ba23a4575f1189689946f._comment deleted file mode 100644 index d60cb2d4d..000000000 --- a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_2_e6ba58c5c31ba23a4575f1189689946f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnR6E5iUghMWdUGlbA9CCs8DKaoigMjJXw" - nickname="Efraim" - subject="comment 2" - date="2013-11-26T09:26:53Z" - content=""" -perhaps he's looking to be able to expand the addurl option to include file://path/to/video.mp4, or for over smb://... , to import a file without changing its location to being inside the annex. -"""]] diff --git a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_3_e53cbc5765819de2d3c742e6cd4d77cd._comment b/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_3_e53cbc5765819de2d3c742e6cd4d77cd._comment deleted file mode 100644 index 23b59574f..000000000 --- a/doc/todo/dumb_plaindir_remote___40__e.g._for_NAS_mounts__41__/comment_3_e53cbc5765819de2d3c742e6cd4d77cd._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE" - nickname="Thomas" - subject="never mind" - date="2013-12-01T18:34:05Z" - content=""" -grossmeier.net did a much better job to explain what I want: -[[New special remote suggeston - clean directory]] - -Please close this issue as duplicate of the above. -"""]] diff --git a/doc/todo/exclude_files_on_a_given_remote.mdwn b/doc/todo/exclude_files_on_a_given_remote.mdwn deleted file mode 100644 index e8bb357d3..000000000 --- a/doc/todo/exclude_files_on_a_given_remote.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -Say I have some files on remote A. But I'm away from it, and transferring -files from B to C. I'd like to avoid transferring any files I already have -on A. - -Something like: - - git annex copy --to C --exclude-on A - -This would not contact A, just use its cached location log info. - -I suppose I might also sometime want to only act on files that are -thought/known to be on A. - - git annex drop --only-on A - ---[[Joey]] - -[[done]] diff --git a/doc/todo/faster_gnupg_cipher.mdwn b/doc/todo/faster_gnupg_cipher.mdwn deleted file mode 100644 index f5ff062d2..000000000 --- a/doc/todo/faster_gnupg_cipher.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Apparently newer gnupg has support for hardware-accelerated AES-NI. It -would be good to have an option to use that. I also wonder if using the -same symmetric key for many files presents a security issues (and whether -using GPG keys directly would be more secure). - -> [[done]]; you can now use encryption=pubkey when setting up a special -> remote to use pure public keys without the hybrid symmetric key scheme. -> Which you choose is up to you. Also, annex.gnupg-options can configure -> the ciphers used. --[[Joey]] diff --git a/doc/todo/faster_gnupg_cipher/comment_1_8f61f7c724a8224e61c015be68f43db7._comment b/doc/todo/faster_gnupg_cipher/comment_1_8f61f7c724a8224e61c015be68f43db7._comment deleted file mode 100644 index 1bf550cdf..000000000 --- a/doc/todo/faster_gnupg_cipher/comment_1_8f61f7c724a8224e61c015be68f43db7._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.145" - subject="comment 1" - date="2013-08-01T17:10:56Z" - content=""" -There is a remote.name.annex-gnupg-options git-config setting that can be used to pass options to gpg on a per-remote basis. - -> also wonder if using the same symmetric key for many files presents a security issues (and whether using GPG keys directly would be more secure). - -I am not a cryptographer, but I have today run this question by someone with a good amount of crypo knowledge. My understanding is that reusing a symmetric key is theoretically vulnerable to eg known-plaintext or chosen-plaintext attacks. And that modern ciphers like AES and CAST (gpg default) are designed to resist such attacks. - -If someone was particularly concerned about these attack vectors, it would be pretty easy to add a mode where git-annex uses public key encryption directly. With the disadvantage, of course, that once a file was sent to a special remote and encrypted for a given set of public keys, other keys could not later be granted access to it. -"""]] diff --git a/doc/todo/faster_gnupg_cipher/comment_2_36e1f227a320527653500b445f7c001c._comment b/doc/todo/faster_gnupg_cipher/comment_2_36e1f227a320527653500b445f7c001c._comment deleted file mode 100644 index 08f69d6b8..000000000 --- a/doc/todo/faster_gnupg_cipher/comment_2_36e1f227a320527653500b445f7c001c._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2013-08-02T07:21:50Z" - content=""" -Using symmetric keys is significantly cheaper, computation-wise. - -The scheme of encrypting symmetric keys with asymmetric ones is ancient, well-proven, and generally accepted as a good approach. - -Using per-key files makes access control more fine-grained and is only a real performance issue once while creating the private key and a little bit every time more than one file needs to be decrypted as more than one symmetric key needs to be taken care of. -"""]] diff --git a/doc/todo/faster_gnupg_cipher/comment_3_bd0c975494333dfe558de048d888ace8._comment b/doc/todo/faster_gnupg_cipher/comment_3_bd0c975494333dfe558de048d888ace8._comment deleted file mode 100644 index d0b98b7f6..000000000 --- a/doc/todo/faster_gnupg_cipher/comment_3_bd0c975494333dfe558de048d888ace8._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="guilhem" - ip="129.16.20.209" - subject="comment 3" - date="2013-08-19T13:44:35Z" - content=""" -AES-NI acceleration will be used by default providing you're using -the new modularized GnuPG (v2.x) and libgcrypt ≥ 1.5.0. Of course it -only speeds up AES encryption, while GnuPG uses CAST by default; you can -either set `personal-cipher-preferences` to AES or AES256 in your -`gpg.conf` or, as joeyh hinted at, set `remote.<name>.annex-gnupg-options` -as described in the manpage. - -By the way, I observed a significant speed up when using `--compress-algo none`. -Image, music and video files are typically hard to compress further, and it seems -that's where gpg spent most of its time, at least on the few files I benchmarked. -"""]] diff --git a/doc/todo/faster_rsync_remotes.mdwn b/doc/todo/faster_rsync_remotes.mdwn deleted file mode 100644 index 8c40b2816..000000000 --- a/doc/todo/faster_rsync_remotes.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Using an rsync remote is currently very slow when there are a lot of files, since rsync appears to be called for each file copied. It would be awesome if each call to rsync was amortized to copy many files; rsync is very good at copying many small files quickly. - -> [[done]]; bug submitter was apparently not using a version -> with rsync connection caching. --[[Joey]] diff --git a/doc/todo/faster_rsync_remotes/comment_1_0bc3ee0ae563357675eeccf42461e59a._comment b/doc/todo/faster_rsync_remotes/comment_1_0bc3ee0ae563357675eeccf42461e59a._comment deleted file mode 100644 index 2f320fee2..000000000 --- a/doc/todo/faster_rsync_remotes/comment_1_0bc3ee0ae563357675eeccf42461e59a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.145" - subject="comment 1" - date="2013-08-01T16:06:42Z" - content=""" -I cannot see a way to do this using rsync's current command-line interface. Ideas how to do it welcomed. -"""]] diff --git a/doc/todo/faster_rsync_remotes/comment_2_ccf6f75450c89ca498c8130054f8d32d._comment b/doc/todo/faster_rsync_remotes/comment_2_ccf6f75450c89ca498c8130054f8d32d._comment deleted file mode 100644 index 67b5feab0..000000000 --- a/doc/todo/faster_rsync_remotes/comment_2_ccf6f75450c89ca498c8130054f8d32d._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawln4uCaqZRd5_nRQ-iLcJyGctIdw8ebUiM" - nickname="Edward" - subject="Just put multiple source files" - date="2013-08-01T16:29:04Z" - content=""" -It seems like you can just put multiple source files on the command line: - - ed@ed-Ubu64 /tmp$ touch a b c d - ed@ed-Ubu64 /tmp$ mkdir test - ed@ed-Ubu64 /tmp$ rsync -avz a b c d test - sending incremental file list - a - b - c - d - - sent 197 bytes received 88 bytes 570.00 bytes/sec - total size is 0 speedup is 0.00 - ed@ed-Ubu64 /tmp$ ls test - a b c d - -It also appears to work with remote transfers too. -"""]] diff --git a/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment b/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment deleted file mode 100644 index 1911048be..000000000 --- a/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.145" - subject="comment 3" - date="2013-08-01T16:58:49Z" - content=""" -git-annex needs to build a specific directory structure on the rsync remote though. It seems it would need to build the whole tree locally, containing only the files it wants to send. - -When using encryption, it would need to encrypt all the files it's going to send and store them locally until it's built the tree. That could use a lot of disk space. - -Also, there's the problem of checking which files are already present in the remote, to avoid re-encrypting and re-sending them. Currently this is done by running rsync with the url of the file, and checking its exit code. rsync does not seem to have an interface that would allow checking multiple files in one call. So any optimisation of the number of rsync calls would only eliminate 1/2 of the current number. - -When using ssh:// urls, the rsync special remote already uses ssh connection caching, which I'd think would eliminate most of the overhead. (If you have a version of git-annex older than 4.20130417, you should upgrade to get this feature.) It should not take very long to start up a new rsync over a cached ssh connection. rsync:// is probably noticably slower. -"""]] diff --git a/doc/todo/faster_rsync_remotes/comment_4_3a2f45defebae3dde336ee5f40c26d7e._comment b/doc/todo/faster_rsync_remotes/comment_4_3a2f45defebae3dde336ee5f40c26d7e._comment deleted file mode 100644 index 44d7d5511..000000000 --- a/doc/todo/faster_rsync_remotes/comment_4_3a2f45defebae3dde336ee5f40c26d7e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawln4uCaqZRd5_nRQ-iLcJyGctIdw8ebUiM" - nickname="Edward" - subject="Thanks" - date="2013-08-01T17:03:23Z" - content=""" -I am using an old version of git-annex. I'll try the newer one and see if the connection caching helps! -"""]] diff --git a/doc/todo/file_copy_progress_bar.mdwn b/doc/todo/file_copy_progress_bar.mdwn deleted file mode 100644 index 847c1d1eb..000000000 --- a/doc/todo/file_copy_progress_bar.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Find a way to copy a file with a progress bar, while still preserving -stat. Easiest way might be to use pv and fix up the permissions etc -after? - -[[done]] diff --git a/doc/todo/fsck.mdwn b/doc/todo/fsck.mdwn deleted file mode 100644 index 1dcaad9a5..000000000 --- a/doc/todo/fsck.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -add a git annex fsck that finds keys that have no referring file - -(done) - -* Need per-backend fsck support. sha1 can checksum all files in the annex. - WORM can check filesize. - -* Both can check that annex.numcopies is satisfied. Probably only - querying the locationlog, not doing an online verification. - -[[done]] diff --git a/doc/todo/fsck_special_remotes.mdwn b/doc/todo/fsck_special_remotes.mdwn deleted file mode 100644 index 7196baafe..000000000 --- a/doc/todo/fsck_special_remotes.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -`git annex fsck --from remote` - -Basically, this needs to receive each file in turn from the remote, to a -temp file, and then run the existing fsck code on it. Could be quite -expensive, but sometimes you really want to check. - -An unencrypted directory special remote could be optimised, by not actually -copying the file, just dropping a symlink, etc. - -The WORM backend doesn't care about file content, so it would be nice to -avoid transferring the content at all, and only send the size. - -> [[done]] --[[Joey]] diff --git a/doc/todo/git-annex-shell.mdwn b/doc/todo/git-annex-shell.mdwn deleted file mode 100644 index a9e3b43ed..000000000 --- a/doc/todo/git-annex-shell.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[done]] - -I've been considering adding a `git-annex-shell` command. This would -be similar to `git-shell` (and in fact would pass unknown commands off to -`git-shell`). - -## Reasons - -* Allows locking down an account to only be able to use git-annex (and - git). -* Avoids needing to construct complex shell commands to run on the remote - system. (Mostly already avoided by the plumbing level commands.) -* Could possibly allow multiple things to be done with one ssh connection - in future. -* Allows expanding `~` and `~user` in repopath on the remote system. diff --git a/doc/todo/git-annex_unused_eats_memory.mdwn b/doc/todo/git-annex_unused_eats_memory.mdwn deleted file mode 100644 index 760a6ccf5..000000000 --- a/doc/todo/git-annex_unused_eats_memory.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -`git-annex unused` has to compare large sets of data -(all keys with content present in the repository, -with all keys used by files in the repository), and so -uses more memory than git-annex typically needs. - -It used to be a lot worse (hundreds of megabytes). - -Now it only needs enough memory to store a Set of all Keys that currently -have content in the annex. On a lightly populated repository, it runs in -quite low memory use (like 8 mb) even if the git repo has 100 thousand -files. On a repository with lots of file contents, it will use more. - -Still, I would like to reduce this to a purely constant memory use, -as running in constant memory no matter the repo size is a git-annex design -goal. - -One idea is to use a bloom filter. -For example, construct a bloom filter of all keys used by files in -the repository. Then for each key with content present, check if it's -in the bloom filter. Since there can be false positives, this might -miss finding some unused keys. The probability/size of filter -could be tunable. - -> Fixed in `bloom` branch in git. --[[Joey]] ->> [[done]]! --[[Joey]] - -Another way might be to scan the git log for files that got removed -or changed what key they pointed to. Correlate with keys with content -currently present in the repository (possibly using a bloom filter again), -and that would yield a shortlist of keys that are probably not used. -Then scan thru all files in the repo to make sure that none point to keys -on the shortlist. diff --git a/doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_message.mdwn b/doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_message.mdwn deleted file mode 100644 index be7e2dacc..000000000 --- a/doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_message.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -Would help alot when having to add large(ish) amounts of remotes. - -Maybe detect this kind of commit message and ask user whether to automatically add them? See [[auto_remotes]]: -> Question: When should git-annex update the remote.log? (If not just on init.) Whenever it reads in a repo's remotes? - ----- - -I'm not sure that the above suggestion is going down a path that really -makes sense. If you want a list of repository UUIDs and descriptions, -it's there in machine-usable form in `.git-annex/uuid.log`, there is no -need to try to pull this info out of git commit messages. --[[Joey]] - -[[done]] diff --git a/doc/todo/gitolite_and_gitosis_support.mdwn b/doc/todo/gitolite_and_gitosis_support.mdwn deleted file mode 100644 index 2fca83986..000000000 --- a/doc/todo/gitolite_and_gitosis_support.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -gitosis and gitolite should support git-annex being used to send/receive -files from the repositories they manage. Users with read-only access -could only get files, while users with write access could also put and drop -files. - -Doing this right requires modifying both programs, to add [[git-annex-shell]] -to the list of things they can run, and only allow through appropriate -git-annex-shell subcommands to read-only users. - -I have posted an RFC for modifying gitolite to the -[gitolite mailing list](http://groups.google.com/group/gitolite?lnk=srg). - -> I have not developed a patch yet, but all that git-annex needs is a way -> to ssh to the server and run the git-annex-shell command there. -> git-annex-shell is very similar to git-shell. So, one way to enable -> it is simply to set GL_ADC_PATH to a directory containing git-annex-shell. -> -> But, that's not optimal, since git-annex-shell will send off receive-pack -> commands to git, which would bypass gitolite's permissions checking. -> Also, it makes sense to limit readonly users to only download, not -> upload/delete files from git-annex. Instead, I suggest adding something -> like this to gitolite's config: - - # If set, users with W access can write file contents into the git-annex, - # and users with R access can read file contents from the git-annex. - $GL_GIT_ANNEX = 0; - -> If this makes sense, I'm sure I can put a patch together for your -> review. It would involve modifying gl-auth-command so it knows how -> to run git-annex-shell, and how to parse out the "verb" from a -> git-annex-shell command line, and modifying R_COMMANDS and W_COMMANDS. - -As I don't write python, someone else is needed to work on gitosis. ---[[Joey]] - -> [[done]]; support for gitolite is in its `pu` branch, and some changes -> made to git-annefor gitolite is in its `pu` branch, and some changes -> made to git-annex. Word is gitosis is not being maintained so I won't -> worry about try to support it. --[[Joey]] diff --git a/doc/todo/gitrm.mdwn b/doc/todo/gitrm.mdwn deleted file mode 100644 index e41c33462..000000000 --- a/doc/todo/gitrm.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -how to handle git rm file? (should try to drop keys that have no -referring file, if it seems safe..) - -[[done]] -- I think that git annex unused and dropunused are the best -solution to this. diff --git a/doc/todo/http_git_annex_404_retry.mdwn b/doc/todo/http_git_annex_404_retry.mdwn deleted file mode 100644 index 69680f0a1..000000000 --- a/doc/todo/http_git_annex_404_retry.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -A repository like http://annex.debconf.org/debconf-share/ has a git repo -published via http. When getting files from such a repo, git-annex tries -two urls. One url would be used by a bare repo, and the other by a non-bare -repo. (This is due to the directory hashing change.) Result is every file -download from a non-bare http repo starts with a 404 and then it retries -with the right url. - -Since git-annex already downloads the .git/config to find the uuid of the -http repo, it could also look at it to see if the repo is bare. If not, -set a flag, and try the two urls in reverse order, which would almost -always avoid this 404 problem. - -(The real solution is probably to flag day and get rid of the old-style -directory hashing, but that's been discussed elsewhere.) - ---[[Joey]] - -[[done]] diff --git a/doc/todo/http_headers.mdwn b/doc/todo/http_headers.mdwn deleted file mode 100644 index 9f61bdc93..000000000 --- a/doc/todo/http_headers.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -The IA would find it useful to be able to control the http headers -git-annex get, addurl, etc uses. This will allow setting cookies, for -example. - -* annex-web-headers=blah -* Perhaps also annex-web-headers-command=blah - -[[done]] diff --git a/doc/todo/immutable_annexed_files.mdwn b/doc/todo/immutable_annexed_files.mdwn deleted file mode 100644 index b26838e95..000000000 --- a/doc/todo/immutable_annexed_files.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -> josh: Do you do anything in git-annex to try to make the files immutable? -> For instance, removing write permission, or even chattr? -> joey: I don't, but that's a very good idea -> josh: Oh, I just thought of another slightly crazy but handy idea. -> josh: I'd hate to run into a program which somehow followed the symlink and then did an unlink to replace the file. -> josh: To break that, you could create a new directory under annex's internal directory for each file, and make the directory have no write permission. - -[[done]] and done --[[Joey]] diff --git a/doc/todo/incremental_fsck.mdwn b/doc/todo/incremental_fsck.mdwn deleted file mode 100644 index 7c56328b9..000000000 --- a/doc/todo/incremental_fsck.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -Justin Azoff realized git-annex should have an incremental fsck. - -This requires storing the last fsck time of each object. - -I would not be strongly opposed to sqlite, but I think there are other -places the data could be stored. One possible place is the mode or mtime -of the .git/annex/objects/xx/yy/$key directories (the parent directories -of where the content is stored). Perhaps the sticky bit could be used to -indicate the content has been fsked, and the mtime indicate the time -of last fsck. Anything that dropped or put in content would need to -clear the sticky bit. --[[Joey]] - -> Basic incremental fsck is done now. -> -> Some enhancements would include: -> -> * --max-age=30d Once the incremental fsck completes and was started 30 days ago, -> start a new one. -> * --time-limit --size-limit --file-limit: Limit how long the fsck runs. - ->> Calling this [[done]]. The `--incremental-schedule` option ->> allows scheduling time between incremental fscks. `--time-limit` is ->> done. I implemented `--smallerthan` independently. Not clear what ->> `--file-limit` would be. --[[Joey]] diff --git a/doc/todo/incremental_fsck/comment_1_609b21141dd5686b2c0eaef2b8d63229._comment b/doc/todo/incremental_fsck/comment_1_609b21141dd5686b2c0eaef2b8d63229._comment deleted file mode 100644 index 709ba078c..000000000 --- a/doc/todo/incremental_fsck/comment_1_609b21141dd5686b2c0eaef2b8d63229._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" - nickname="Justin" - subject="comment 1" - date="2012-09-20T14:11:57Z" - content=""" -I have a [proof of concept written in python](https://github.com/JustinAzoff/git-annex-background-fsck/blob/master/git-annex-background-fsck). - -You can run it and point it the root of an annex or to a subdirectory. In my brief testing it seems to work :-) - -the goal would be to have options like - - git annex fsck /data/annex --check-older-than 1w --check-for 2h --max-load-avg 0.5 -"""]] diff --git a/doc/todo/link_file_to_remote_repo_feature.mdwn b/doc/todo/link_file_to_remote_repo_feature.mdwn deleted file mode 100644 index d6b41e805..000000000 --- a/doc/todo/link_file_to_remote_repo_feature.mdwn +++ /dev/null @@ -1,52 +0,0 @@ -I have two repos, using SHA1 backend and both using git. -The first one is a laptop, the second one is a usb drive. - -When I drop a file on the laptop repo, the file is not available on that repo until I run *git annex get* -But when the usb drive is plugged in the file is actually available. - -How about adding a feature to link some/all files to the remote repo? - -e.g. -We have *railscasts/196-nested-model-form-part-1.mp4* file added to git, and only available on the usb drive: - - $ git annex whereis 196-nested-model-form-part-1.mp4 - whereis 196-nested-model-form-part-1.mp4 (1 copy) - a7b7d7a4-2a8a-11e1-aebc-d3c589296e81 -- origin (Portable usb drive) - -I can see the link with: - - $ cd railscasts - $ ls -ls 196* - 8 lrwxr-xr-x 1 framallo staff 193 Dec 20 05:49 196-nested-model-form-part-1.mp4 -> ../.git/annex/objects/Wz/6P/SHA256-s16898930--43679c67cd968243f58f8f7fb30690b5f3f067574e318d609a01613a2a14351e/SHA256-s16898930--43679c67cd968243f58f8f7fb30690b5f3f067574e318d609a01613a2a14351e - -I save this in a variable just to make the example more clear: - - ID=".git/annex/objects/Wz/6P/SHA256-s16898930--43679c67cd968243f58f8f7fb30690b5f3f067574e318d609a01613a2a14351e/SHA256-s16898930--43679c67cd968243f58f8f7fb30690b5f3f067574e318d609a01613a2a14351e" - -The file doesn't exist on the local repo: - - $ ls ../$ID - ls: ../$ID: No such file or directory - -however I can create a link to access that file on the remote repo. -First I create a needed dir: - - $ mkdir ../.git/annex/objects/Wz/6P/SHA256-s16898930--43679c67cd968243f58f8f7fb30690b5f3f067574e318d609a01613a2a14351e/ - -Then I link to the remote file: - - $ ln -s /mnt/usb_drive/repo_folder/$ID ../$ID - -now I can open the file in the laptop repo. - - -I think it could be easy to implement. Maybe It's a naive approach, but looks apealing. -Checking if it's a real file or a link shouldn't impact on performance. -The limitation is that it would work only with remote repos on local dirs - -Also allows you to have one directory structure like AFS or other distributed FS. If the file is not local I go to the remote server. -Which is great for apps like Picasa, Itunes, and friends that depends on the file location. - -> This is a duplicate of [[union_mounting]]. So closing it: [[done]]. -> -> It's a good idea, but making sure git-annex correctly handles these links in all cases is a subtle problem that has not yet been tackled. --[[Joey]] diff --git a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option.mdwn b/doc/todo/make___34__itemdate__34___valid_importfeed_template_option.mdwn deleted file mode 100644 index 9b6f6ce7c..000000000 --- a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -Some podcasts don't include a sortable date as the first thing in their episode title, which makes listening to them in order challenging if not impossible. - -The date the item was posted is part of the RSS standard, so we should parse that and provide a new importfeed template option "itemdate". - -(For the curious, I tried "itemid" thinking that might give me something close, but it doesn't. I used --template='${feedtitle}/${itemid}-${itemtitle}${extension}' and get: - - http___openmetalcast.com__p_1163-Open_Metalcast_Episode__93__Headless_Chicken.ogg - -or - - http___www.folkalley.com_music_podcasts__name_2013_08_21_alleycast_6_13.mp3-Alleycast___06.13.mp3 - -that "works" but is ugly :) - -Would love to be able to put a YYYYMMDD at the beginning and then the title. - -> [[done]]; itempubdate will use form YYYY-MM-DD (or the raw date string -> if the feed does not use a parsable form). --[[Joey]] diff --git a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_1_9fa523d1eabb6e029a91413770e9af72._comment b/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_1_9fa523d1eabb6e029a91413770e9af72._comment deleted file mode 100644 index c9cf2ba51..000000000 --- a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_1_9fa523d1eabb6e029a91413770e9af72._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://grossmeier.net/" - nickname="greg" - subject="Without knowing Haskell" - date="2014-04-06T04:55:31Z" - content=""" -Maybe this just requires adding: - - , fieldMaybe \"itemdate\" $ getFeedPubDate $ item i - -on line 214 in Command/ImportFeed.hs ?? - -It is supported by [Text.Feed.Query](http://hackage.haskell.org/package/feed-0.3.9.2/docs/Text-Feed-Query.html) - -I have no haskell dev env so I can't test this, but if my suggestion is true, I might set one up :) -"""]] diff --git a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_2_9090bb66713f48fbdd1e2a3f1292b7ba._comment b/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_2_9090bb66713f48fbdd1e2a3f1292b7ba._comment deleted file mode 100644 index 8ebc5fcd7..000000000 --- a/doc/todo/make___34__itemdate__34___valid_importfeed_template_option/comment_2_9090bb66713f48fbdd1e2a3f1292b7ba._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.244" - subject="comment 2" - date="2014-04-07T19:51:27Z" - content=""" -https://github.com/sof/feed/issues/6 -"""]] diff --git a/doc/todo/makefile:_respect___36__PREFIX.mdwn b/doc/todo/makefile:_respect___36__PREFIX.mdwn deleted file mode 100644 index 995ef809f..000000000 --- a/doc/todo/makefile:_respect___36__PREFIX.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -The `Makefile` should respect a `PREFIX` passed on the commandline so git-annex can be installed in (say) `$HOME`. - -Simple patch: - -[[!format diff """ -diff --git a/Makefile b/Makefile -index b8995b2..5b1a6d4 100644 ---- a/Makefile -+++ b/Makefile -@@ -3,7 +3,7 @@ all=git-annex $(mans) docs - - GHC?=ghc - GHCMAKE=$(GHC) $(GHCFLAGS) --make --PREFIX=/usr -+PREFIX?=/usr - CABAL?=cabal # set to "./Setup" if you lack a cabal program - - # Am I typing :make in vim? Do a fast build. -"""]] - ---[[anarcat]] - -> [[done]] --[[Joey]] - -> > thanks! ;) --[[anarcat]] diff --git a/doc/todo/mdwn2man:_make_backticks_bold.mdwn b/doc/todo/mdwn2man:_make_backticks_bold.mdwn deleted file mode 100644 index 21707a309..000000000 --- a/doc/todo/mdwn2man:_make_backticks_bold.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -The traditionnal way of marking commandline flags in a manpage is with a `.B` (for Bold, I guess). It doesn't seem to be used by mdwn2man, which makes the manpage look a little more dull than it could. - -The following patch makes those options come out more obviously: - -[[!format diff """ -diff --git a/Build/mdwn2man b/Build/mdwn2man -index ba5919b..7f819ad 100755 ---- a/Build/mdwn2man -+++ b/Build/mdwn2man -@@ -8,6 +8,7 @@ print ".TH $prog $section\n"; - - while (<>) { - s{(\\?)\[\[([^\s\|\]]+)(\|[^\s\]]+)?\]\]}{$1 ? "[[$2]]" : $2}eg; -+ s/\`([^\`]*)\`/\\fB$1\\fP/g; - s/\`//g; - s/^\s*\./\\&./g; - if (/^#\s/) { -"""]] - -I tested it against the git-annex manpage and it seems to work well. --[[anarcat]] - -> [[done]], thanks --[[Joey]] diff --git a/doc/todo/network_remotes.mdwn b/doc/todo/network_remotes.mdwn deleted file mode 100644 index 42efa832f..000000000 --- a/doc/todo/network_remotes.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Support for remote git repositories (ssh:// specifically can be made to -work, although the other end probably needs to have git-annex -installed..) - -[[done]], at least get and put work.. diff --git a/doc/todo/nicer_whereis_output.mdwn b/doc/todo/nicer_whereis_output.mdwn deleted file mode 100644 index 871eee01a..000000000 --- a/doc/todo/nicer_whereis_output.mdwn +++ /dev/null @@ -1,100 +0,0 @@ -We had some informal discussions on IRC about improving the output of the `whereis` command. - -[[!toc levels=2]] - -First version: columns -====================== - -[[mastensg]] started by implementing a [simple formatter](https://gist.github.com/mastensg/6500982) that would display things in columns [screenshot](http://www.ping.uio.no/~mastensg/whereis.png) - -Second version: Xs -================== - -After some suggestions from [[joey]], [[mastensg]] changed the format slightly ([screenshot](http://www.ping.uio.no/~mastensg/whereis2.png)): - -[[!format txt """ -17:01:34 <joeyh> foo -17:01:34 <joeyh> |bar -17:01:34 <joeyh> ||baz (untrusted) -17:01:34 <joeyh> ||| -17:01:34 <joeyh> XXx 3? img.png -17:01:36 <joeyh> _X_ 1! bigfile -17:01:37 <joeyh> XX_ 2 zort -17:01:39 <joeyh> __x 1?! maybemissing -17:02:09 * joeyh does a s/\?/+/ in the above -17:02:24 <joeyh> and decrements the counters for untrusted -17:03:37 <joeyh> __x 0+! maybemissing -"""]] - -Third version: incremental -========================== - -Finally, [[anarcat]] worked on making it run faster on large repositories, in a [fork](https://gist.github.com/anarcat/6502988) of that first gist. Then paging was added (so headers are repeated). - -Fourth version: tuning and blocked -================================== - -[[TobiasTheViking]] provided some bugfixes, and the next step was to implement the trusted/untrusted detection, and have a counter. - -This required more advanced parsing of the remotes, and instead of starting to do some JSON parsing, [[anarcat]] figured it was time to learn some Haskell instead. - -Current status: needs merge -=========================== - -So right now, the most recent version of the python script is in [anarcat's gist](https://gist.github.com/anarcat/6502988) and works reasonably well. However, it doesn't distinguish between trusted and untrusted repos and so on. - -Furthermore, we'd like to see this factored into the `whereis` command directly. A [raw.hs](http://codepad.org/miVJb5oK) file has been programmed by `mastensg`, and is now available in the above gist. It fits the desired output and prototypes, and has been `haskellized` thanks to [[guilhem]]. - -Now we just need to merge those marvelous functions in `Whereis.hs` - but I can't quite figure out where to throw that code, so I'll leave it to someone more familiar with the internals of git-annex. The most recent version is still in [anarcat's gist](https://gist.github.com/anarcat/6502988). --[[anarcat]] - -Desired output --------------- - -The output we're aiming for is: - - foo - |bar - ||baz (untrusted) - ||| - XXx 2+ img.png - _X_ 1! bigfile - XX_ 2 zort - __x 0+! maybemissing - -Legend: - - * `_` - file missing from repo - * `x` - file may be present in untrusted repo - * `X` - file is present in trusted repo - * `[0-9]` - number of copies present in trusted repos - * `+` - indicates there may be more copies present - * `!` - indicates only one copy is left - -Implementation notes --------------------- - -[[!format txt """ -20:48:18 <joeyh> if someone writes me a headerWhereis :: [(RemoteName, TrustLevel)] -> String and a formatWhereis :: [(RemoteName, TrustLevel, UUID)] -> [UUD] -> FileName -> String , I can do the rest ;) -20:49:22 <joeyh> make that second one formatWhereis :: [(RemoteName, TrueLevel, Bool)] -> FileName -> String -20:49:37 <joeyh> gah, typos -20:49:45 <joeyh> suppose you don't need the RemoteName either -"""]] - -> So, I incorporated this, in a new remotes command. -> Showing all known repositories seemed a bit much -> (I have 30-some known repositories in some cases), -> so just showing configured remotes seems a good simplification. -> [[done]] -> --[[Joey]] - -> > I would have prefered this to be optional since I don't explicitely configure all remotes in git, especially if I can't reach them all the time (e.g. my laptop). It seems to me this should at least be an option, but I am confused as to why `Remote.List.remoteList` doesn't list all remotes the same way `Remote.remote_list` does... Also, it's unfortunate that the +/!/count flags have been dropped, it would have been useful... Thanks for the merge anyways! --[[done]] -> > -> > The more I look at this, the more i think there are a few things wrong with the new `remotes` command. -> > -> > 1. the name is confusing: being a git addict, I would expect the `git annex remote` command to behave like the `git remote` command: list remotes, add remotes, remove remotes and so on. it would actually be useful to have such a command (which would replace `initremote`, I guess). i recommend replacing the current `whereis` command, even if enabled through a special flag -> > -> > 2. its behavior is inconsistent with other git annex commands: `git annex status`, for example, lists information about all remotes, regardless of whether they are configured in git. `remotes` (whatever it's called), should do the same, or at least provide an option to allow the user to list files on all remotes. The way things stand, there is no way to list files on non-git remotes, even if they are added explicitely as a remote, if the remote is not actually reachable: the files are just marked as absent (even thought `whereis` actually finds them). i recommend showing all remotes regardless, either opt-in or opt-out using a flag. -> > -> > 3. having the `!` flag, at least, would be useful because it would allow users to intuitively grep for problematic files without having to learn extra syntax. same with + and having an explicit count. -> > -> > thanks. --[[anarcat]] diff --git a/doc/todo/object_dir_reorg_v2.mdwn b/doc/todo/object_dir_reorg_v2.mdwn deleted file mode 100644 index 49666ddc7..000000000 --- a/doc/todo/object_dir_reorg_v2.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -Several things suggest now would be a good time to reorgaize the object -directory. This would be annex.version=2. It will be slightly painful for -all users, so this should be the *last* reorg in the forseeable future. - -1. Remove colons from filenames, for [[bugs/fat_support]] - -2. Add hashing, since some filesystems do suck (like er, fat at least :) - [[forum/hashing_objects_directories]] - (Also, may as well hash .git-annex/* while at it -- that's what - really gets big.) - -3. Add filesize metadata for [[bugs/free_space_checking]]. (Currently only - present in WORM, and in an ad-hoc way.) - -4. Perhaps use a generic format that will allow further metadata to be - added later. For example, - "bSHA1,s101111,kf3101c30bb23467deaec5d78c6daa71d395d1879" - - (Probably everything after ",k" should be part of the key, even if it - contains the "," separator character. Otherwise an escaping mechanism - would be needed.) - -[[done]] now! - -Although [[bugs/free_space_checking]] is not quite there --[[Joey]] diff --git a/doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._comment b/doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._comment deleted file mode 100644 index 261c2a51f..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-03-16T01:16:48Z" - content=""" -If you support generic meta-data, keep in mind that you will need to do conflict resolution. Timestamps may not be synched across all systems, so keeping a log of old metadata could be used, sorting by history and using the latest. Which leaves the situation of two incompatible changes. This would probably mean manual conflict resolution. You will probably have thought of this already, but I still wanted to make sure this is recorded. -- RichiH -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._comment b/doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._comment deleted file mode 100644 index 9785f1989..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2011-03-16T01:19:25Z" - content=""" -Hmm, I added quite a few comments at work, but they are stuck in moderation. Maybe I forgot to log in before adding them. I am surprised this one appeared immediately. -- RichiH -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._comment b/doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._comment deleted file mode 100644 index 886941be7..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-03-15T14:08:41Z" - content=""" -What is the potential time-frame for this change? As I am not using git-annex for production yet, I can see myself waiting to avoid any potential hassle. - -Supporting generic metadata seems like a great idea. Though if you are going this path, wouldn't it make sense to avoid metastore for mtime etc and support this natively without outside dependencies? - --- RichiH -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._comment b/doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._comment deleted file mode 100644 index 475359abb..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 4" - date="2011-03-16T03:22:45Z" - content=""" -Well, I spent a few hours playing this evening in the 'reorg' branch in git. It seems to be shaping up pretty well; type-based refactoring in haskell makes these kind of big systematic changes a matter of editing until it compiles. And it compiles and test suite passes. But, so far I've only covered 1. 3. and 4. on the list, and have yet to deal with upgrades. - -I'd recommend you not wait before using git-annex. I am committed to provide upgradability between annexes created with all versions of git-annex, going forward. This is important because we can have offline archival drives that sit unused for years. Git-annex will upgrade a repository to current standard the first time it sees it, and I hope the upgrade will be pretty smooth. It was not bad for the annex.version 0 to 1 upgrade earlier. The only annoyance with upgrades is that it will result in some big commits to git, as every symlink in the repo gets changed, and log files get moved to new names. - -(The metadata being stored with keys is data that a particular backend can use, and is static to a given key, so there are no merge issues (and it won't be used to preserve mtimes, etc).) -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._comment b/doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._comment deleted file mode 100644 index 2032bce3c..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 5" - date="2011-03-16T15:51:30Z" - content=""" -Hashing & segmenting seems to be around the corner, which is nice :) - -Is there a chance that you will optionally add mtime to your native metadata store? If yes, I'd rather wait for v2 to start with the native system from the start. If not, I will probably set it up tonight. - -PS: While posting from work, my comments are held for moderation once again. I am somewhat confused as to why this happens when I can just submit directly from home. And yes, I am using the same auth provider and user in both cases. -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._comment b/doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._comment deleted file mode 100644 index ff86e3970..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 6" - date="2011-03-16T16:32:52Z" - content=""" -The mtime cannot be stored for all keys. Consider a SHA1 key. The mtime is irrelevant; 2 files with different mtimes, when added to the SHA1 backend, should get the same key. - -Probably our spam filter doesn't like your work IP. -"""]] diff --git a/doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._comment b/doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._comment deleted file mode 100644 index fc866c57a..000000000 --- a/doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 7" - date="2011-03-16T21:05:38Z" - content=""" -Ah, OK. I assumed the metadata would be attached to a key, not part of the key. This seems to make upgrades/extensions down the line harder than they need to be, but you are right that this way, merges are not, and never will be, an issue. - -Though with the SHA1 backend, changing files can be tracked. This means that tracking changes in mtime or other is possible. It also means that there are potential merge issues. But I won't argue the point endlessly. I can accept design decisions :) - -The prefix at work is from a university netblock so yes, it might be on a few hundred proxy lists etc. -"""]] diff --git a/doc/todo/optinally_transfer_file_unencryptedly.mdwn b/doc/todo/optinally_transfer_file_unencryptedly.mdwn deleted file mode 100644 index ef27dc521..000000000 --- a/doc/todo/optinally_transfer_file_unencryptedly.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -I have a git-annex repository on a NSLU 2, and transfers are much slower over ssh compared to unencrypted transfers (no wonder at that CPU speed). For the files that I am transferring, no encryption would be necessary. Unfortunately, ssh in Debian does not support "-c none" to disable encryption. - -It would be nice if git-annex would have a way of conveniently transferring files in another way than SSH. I’m not sure what a good way would be – maybe launching a one-shot HTTP-server on the sending end? Haskell libraries for that would be available... Of course it is not always the case that the host reachable with "ssh foo" is also reachable via TCP at "foo:1234"... And there are surely more problem. But still, it would be nice :-) - -> Setting `remote.name.annex-rsync-transport = rsh` will now -> make rsync special remotes use rsh instead of ssh. [[done]] diff --git a/doc/todo/optinally_transfer_file_unencryptedly/comment_1_4be47e7ac85d0f4e7029a96b615545a7._comment b/doc/todo/optinally_transfer_file_unencryptedly/comment_1_4be47e7ac85d0f4e7029a96b615545a7._comment deleted file mode 100644 index 948845b23..000000000 --- a/doc/todo/optinally_transfer_file_unencryptedly/comment_1_4be47e7ac85d0f4e7029a96b615545a7._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="guilhem" - ip="129.16.20.212" - subject="rsh?" - date="2013-04-09T16:11:50Z" - content=""" -I don't use it myself, but rsync can be used with others remote shells, among which rsh supports unencrypted streams. You probably want to set up a secure authorization mechanism to deny access to intruders, and for that kerberos comes to the rescue :-) I didn't try the combination, but it should work over git-annex already. -"""]] diff --git a/doc/todo/preferred_content_numcopies_check.mdwn b/doc/todo/preferred_content_numcopies_check.mdwn deleted file mode 100644 index 2e007460f..000000000 --- a/doc/todo/preferred_content_numcopies_check.mdwn +++ /dev/null @@ -1,86 +0,0 @@ -The assistant and git annex sync --content do not try to proactively -download content that is not otherwise wanted in order to get numcopies -satisfied. (Unlike get --auto, which does take numcopies into account.) - -Should these automated systems try to proactively satisfy numcopies? I -don't feel they should. It could result in surprising results. For example, -a transfer repository, which is of limited size, could start being filled -up with lots of content that all clients have, just because numcopies was -set to a larger number than the total number of clients. Another example, -a source repository on eg an Android phone, should never have content in it -that was not created on that device. - -However, it would make sense for some specific -types of repositories to proactively get content to satisfy numcopies. -Currently some types of repositories use "or (not copies=semitrusted+:1)", -to ensure that if the only copy of a file is on a dead repository, they -will try to get that file before the repo goes away. This is done -by client repositories, and backup, and archive. Probably the same set -would make sense to proactively satisfy numcopies. - -So, a new type of preferred content expression is called for. Such as, for -example, "numcopiesneeded=1". Which indicates that at least 1 more copy -is needed to satifsy numcopies. - -(Note that it should only count semittrusted and higher trust -level repos as satisfying numcopies.) - -But, preferred content expressions can only operate on info stored in the -git repo, or they will fail to be stable. Ie, repo A needs to be able to -calculate whether a file is preferred content by repo B and get the same -result as when repo B calculates that. - -numcopies is currently configured in 3 places: - -* .git/config `annex.numcopies` (global, stored only locally) -* .gitattributes `annex.numcopies` (per file, stored in git repo) -* --numcopies (not relevant) - -So, need to add a global numcopies setting that is stored in the git repo. -That could either be a file in the git-annex branch, or just -`* annex.numcopies=2` in the toplevel .gitattributes. Note that the -assistant needs to be able to query and set it, which I think argues -against using .gitattributes for it. Also arguing against that is that the -.git/config numcopies valie applies even to objects with no file in the -work tree, which gitattributes settings do not. - -Conclusion: - -* Add to the git-annex branch a numcopies file that holds the global - numcopies default if present. **done** -* Modify the assistant to use it when configuring numcopies. **done** -* To deprecate .git/config's annex.numcopies, only make it take effect - when there is no numcopies file in the git-annex branch. **done** -* Add "numcopiesneeded=N" preferred content expression using the git-annex - branch numcopies setting, overridden by any .gitattributes numcopies setting - for a particular file. It should ignore the other ways to specify - numcopies, particularly git config annex.numcopies. **done** -* Make the repo groups that currently end with "or (not copies=semitrusted+:1)" - to instead end with "or numcopiesneeded=1" **done** -* See if "numcopiesneeded=N" can check .gitattributes without getting - a lot slower. If now, perhaps add a "numcopiesneededaccurate=N" that - checks it. **done** - -[[done]] - -## Stability analysis - -If a remote prefers eg, "blah or numcopiesneeded=1", and -file $foo does not match blah, but needs more copies, then then the -expression will match. - -So, git-annex will get $foo, adding a copy. Which means that the -numcopiesneeded=1 will no longer match, so the file is no longer wanted -now that it has been downloaded. - -Now there are two cases for what can happen: - -* git-annex tries to drop $foo, but fails because it cannot find enough - other copies -* git-annex copies $foo to some other remote that wants it, and then - manages to drop $foo from the local remote. - -This seems ok. Files flow through repos and they act like transfer -repos when there are not enough copies. - ---[[Joey]] diff --git a/doc/todo/pushpull.mdwn b/doc/todo/pushpull.mdwn deleted file mode 100644 index 6828b35b2..000000000 --- a/doc/todo/pushpull.mdwn +++ /dev/null @@ -1,4 +0,0 @@ ---push/--pull should take a reponame and files, and push those files - to that repo; dropping them from the current repo - -[[done]] (move --from/--to) diff --git a/doc/todo/quvi_0.9_support.mdwn b/doc/todo/quvi_0.9_support.mdwn deleted file mode 100644 index 36280452a..000000000 --- a/doc/todo/quvi_0.9_support.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -quvi 0.9 has a completely different interface; git-annex needs to be made -to detect and use it. - -I have already fixed the worst problem, which caused git-annex addurl to -think that every url was a valid quvi url. --[[Joey]] - -> [[done]], 0.9 is supported, although the version is detected at build -> time. --[[Joey]] diff --git a/doc/todo/rsync.mdwn b/doc/todo/rsync.mdwn deleted file mode 100644 index 3353f19c4..000000000 --- a/doc/todo/rsync.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Transferring a file from a ssh:// remote should use rsync to allow resuming -of a prior transfer. - -[[done]] diff --git a/doc/todo/separate_rsync_bwlimit_options_for_upload_and_download.mdwn b/doc/todo/separate_rsync_bwlimit_options_for_upload_and_download.mdwn deleted file mode 100644 index 2b93ad2d6..000000000 --- a/doc/todo/separate_rsync_bwlimit_options_for_upload_and_download.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -The bandwidth for upload and download are often different. It would be useful to have different settings for upload and download limits. -As it is, I have to keep changing annex-rsync-options options between uploads and downloads. - -> [[done]] --[[Joey]] diff --git a/doc/todo/special_remote_for_amazon_glacier.mdwn b/doc/todo/special_remote_for_amazon_glacier.mdwn deleted file mode 100644 index 9b8b9d74e..000000000 --- a/doc/todo/special_remote_for_amazon_glacier.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Amazon's new glacier service would be a nice special remote to support for -long-term archival. - -The main difficulty is that glacier is organized into vaults, and accessing -a file in a vault takes ~4 hours. A naive implementation would make `git -annex get` wait for 4 hours, which is certainly not reasonable. - -One approach I am pondering is to make each glacier vault a separate -special remote. You could then request git-annex to spin up a remote, and -come back later, and be able to access the data stored in it (need to check -if glacier would also allow adding new data to it then). This is -conceptually similar to using git-annex with offline removable drives, -except with glacier, you have a controllable robot to get them plugged in. :) - -Ideally, git-annex would arrange for glacier to send it a message when the -vault becomes available, and the user could queue a list of commands to -run, or files to transfer, at that point. - ---[[Joey]] - -> [[done]]! --[[Joey]] - ------ - -> In the coming months, Amazon S3 will introduce an option that will allow customers to seamlessly move data between Amazon S3 and Amazon Glacier based on data lifecycle policies. - --- <http://aws.amazon.com/glacier/faqs/#How_should_I_choose_between_Amazon_Glacier_and_Amazon_S3> - ->> They did, but it's IMHO not very useful for git-annex. It's rather ->> intended to allow aging S3 storage out to Glacier. --[[Joey]] diff --git a/doc/todo/special_remote_for_amazon_glacier/comment_1_68f129441eefcbfebf7a9db680f52759._comment b/doc/todo/special_remote_for_amazon_glacier/comment_1_68f129441eefcbfebf7a9db680f52759._comment deleted file mode 100644 index 68593be42..000000000 --- a/doc/todo/special_remote_for_amazon_glacier/comment_1_68f129441eefcbfebf7a9db680f52759._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://mike.magin.org/" - nickname="mmagin" - subject="comment 1" - date="2012-09-14T04:19:53Z" - content=""" -When I first heard about Glacier, it sounded great for a cheap backup copy, and I was thinking about writing a \"hook\" remote, but once I read some better analysis of the pricing (e.g. [[http://www.daemonology.net/blog/2012-09-04-thoughts-on-glacier-pricing.html]]) I rapidly lost interest. -"""]] diff --git a/doc/todo/special_remote_for_amazon_glacier/comment_2_c5eeaf8ceee414fa0379831ca52e290c._comment b/doc/todo/special_remote_for_amazon_glacier/comment_2_c5eeaf8ceee414fa0379831ca52e290c._comment deleted file mode 100644 index 701047f91..000000000 --- a/doc/todo/special_remote_for_amazon_glacier/comment_2_c5eeaf8ceee414fa0379831ca52e290c._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="basak" - subject="comment 2" - date="2012-09-21T22:21:04Z" - content=""" -I've created a glacier command line interface that integrates with git-annex [here](https://github.com/basak/glacier-cli), currently using the hook special remote mechanism. To get around the time delay, operations which require a job submission will submit the job and then fail. Retrying again four hours later should then succeed. It seems to work pretty well with git-annex. -"""]] diff --git a/doc/todo/speed_up_fsck.mdwn b/doc/todo/speed_up_fsck.mdwn deleted file mode 100644 index 5d5e867f8..000000000 --- a/doc/todo/speed_up_fsck.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -moving to the git-annex branch has slowed down fsck worse than most -commands. Actually, some commands have sped up, while others like get -are slightly slower but are swamped by the normal runtime. - -For fsck though, it has to pull each file's location log info out of git. -And, it's typically run on the entire tree. - -Another slow one in `git annex copy --from`. - -It would be possible to run a single `git cat-file --batch` and pass it -sha1s of location logs for file that is going to be fsked (gotten via -`read-tree`). Then just read its output until the next requested sha1 to -chunk it, and pass this in to fsck in a closure. - -The difficulty, besides writing that is that everything that works with -location logs now reads them out of git, would need to find a way to -provide the info on a side channel of some sort. - -If this is implemented, the same infrastructure could be used for other -commands like whereis and add. --[[Joey]] - -> Updated plan: -> -> Run `git ls-file --batch`, and cache its stdin and out handles in Branch -> state. -> -> To see a git-annex branch file, send it something like -> "git-annex:uuid.log", and read the content fron stdout handle. -> -> To detect the end of content, send "TOKEN\n", and look for -> "TOKEN missing" in its output. A good choice for TOKEN is anything -> that will never exist in the repo; 40 0's would be a fairly good choice, -> but even better seems to be something completely invalid and impossible -> to have as a sha1 or filename or ref: "". -> -> Hmm, except that's actually an error message sent to stderr. Unless -> stderr is connected to stdout, it might be better to look for a known, -> empty object. Could just add a git-annex:empty file to that end. - -[[done]] --[[Joey]] diff --git a/doc/todo/support-non-utf8-locales.mdwn b/doc/todo/support-non-utf8-locales.mdwn deleted file mode 100644 index da40118d5..000000000 --- a/doc/todo/support-non-utf8-locales.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -Currenty, git-annex forces output, particularly of filenames, in a utf-8 -locale. - -Note that this does not mean it cannot be used with filenames in other -encodings. git-annex is entirely encoding agnostic when it comes to -manipulating filenames. It just *displays* their names always converted to -utf-8, which may not look right when you have a non-utf8 locale. - -This had to be done to work around some bugs with haskell's handling -of filename encodings. In particular, - -* [[bugs/unhappy_without_UTF8_locale]]: haskell crashes when told to output - a string with characters > 255 in a non-utf8 locale. -* [[bugs/problems_with_utf8_names]]: On many OSs, haskell expects - non-decoded raw char8 in FilePaths. In order to display a filename, - though, it needs to first be decoded, and git-annex currently assumes - it was encoded as utf8. - -git-annex's behavior is unlikely to improve much until haskell's -support for utf8 filenames improves. --[[Joey]] - -> [[done]] -- I just turned off all encoding handling on stdout and stderr, -> which avoids these problems nicely. Git-annex now displays just what it -> input, at least on platforms where haskell does not decode unicode in -> FilePaths. This will later be a problem when it gets localized, but for -> now works great. --[[Joey]] diff --git a/doc/todo/support_for_lossy_remotes.mdwn b/doc/todo/support_for_lossy_remotes.mdwn deleted file mode 100644 index 23083b2d7..000000000 --- a/doc/todo/support_for_lossy_remotes.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I'm curious if there's a possibility to support lossy remotes. It may be handy to support syncing to special remotes that do lossy compression on the files (e.g., videos and images). For example, one could imagine having a YouTube special remote that only syncs video files. The original files wouldn't be available for download due to the transcoding and compression that YouTube does, so they wouldn't count towards the number of copies. In this YouTube example, the user gains: - -1. an online place that their videos are available from -2. a worst-case scenario "backup" -3. a remote that they could download smaller video files - -> [[done]]; lossy remotes are supported as seen with `git annex addurl -> --fast` and also with the new addurl support for using quvi to get -> videos fro youtube. Just make a key with a URL or something in it, and -> no size or checksum, and any content will be assumed to be the right -> content. --[[Joey]] diff --git a/doc/todo/support_for_lossy_remotes/comment_1_f5cd9f9deab13ab2d2290ad763906dd3._comment b/doc/todo/support_for_lossy_remotes/comment_1_f5cd9f9deab13ab2d2290ad763906dd3._comment deleted file mode 100644 index 1e895944c..000000000 --- a/doc/todo/support_for_lossy_remotes/comment_1_f5cd9f9deab13ab2d2290ad763906dd3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.90" - subject="comment 1" - date="2013-07-16T19:16:54Z" - content=""" -There is already one example of a lossy remote: If you use `git annex addurl --relaxed` it generates a key that just uses the url, without its size. When retreiving such a key, any content will be accepted. -"""]] diff --git a/doc/todo/support_for_writing_external_special_remotes.mdwn b/doc/todo/support_for_writing_external_special_remotes.mdwn deleted file mode 100644 index 1732f77ea..000000000 --- a/doc/todo/support_for_writing_external_special_remotes.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -It would be good to have something in between the hook special remote and -the built-in special remotes. The hook is easy to set up, but its simple -interface misses some features that a more full-features interface could -provide to a third-party program that wants to provide the best possible -special remote it can w/o being written in haskell: - -* No way to send progress updates when uploading, so no progress bars for uploads from hook special remotes in the webapp. -* No way to verify the `initremote` parameters include all needed configuration, and do any initalization needed. -* No way to query and/or set the remote.log while it's running. (Well, technically, `git annex enableremote` can set values..) -* No way to store per-key information to the git-annex branch. -* No (easy) way to split files into chunks. - -Some of these features could be added to git-annex as subcommands. Which would -improve the general programmability and flexability of git-annex. OTOH, -running `git-annex upload-progress` repeatedly is pretty ugly. Or the -interface could provide a channel for the program and git-annex to -communicate back and forth on. Maybe a mix of the two? - -A final feature such an interface should provide is the ability to drop a -program into PATH and have it just work, without the user needing to do any -configuration beyond `initremote`. So, `git annex initremote foo type=$bar` -should look for `git-annex-remote-$bar` in PATH if that's not a built-in -special remote name. - ---[[Joey]] - -[[done]] diff --git a/doc/todo/support_fsck_in_bare_repos.mdwn b/doc/todo/support_fsck_in_bare_repos.mdwn deleted file mode 100644 index 32ced467e..000000000 --- a/doc/todo/support_fsck_in_bare_repos.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -What is says on the tin: - - 22:56:54 < RichiH> joeyh_: by the way, i have been thinking about fsck on bare repos - 22:57:37 < RichiH> joeyh_: the best i could come with is to have a bare and a non-bare access the same repo store - 22:58:00 < RichiH> joeyh_: alternatively, with the SHA* backend, you have all the information to verify that the local data is correct - 22:58:41 < RichiH> and verifying that would already be a plus. if there really _is_ a problem, having the SHA is enough to track issues down - 23:09:50 < joeyh_> oh, I think I have code that fsck could use on bare repos already.. just a matter of wiring it up - 23:10:42 < joeyh_> feel free to reopen a bug or whatever so I remember.. the unused command's branch content enumeration could be used in a bare repo - 23:14:51 < joeyh_> unused/dropunused could work in bare repos too btw - -> Also `status`'s total annex keys/size could be handled for bare repos. --[[Joey]] - ->> Fsck is done. Rest not done yet. --[[Joey]] - ->>> all [[done]]! --[[Joey]] - -[[!meta title="support unused, dropunused in bare repos"]] diff --git a/doc/todo/symlink_farming_commit_hook.mdwn b/doc/todo/symlink_farming_commit_hook.mdwn deleted file mode 100644 index 3e93cb34b..000000000 --- a/doc/todo/symlink_farming_commit_hook.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -TODO: implement below - -git-annex does use a lot of symlinks. Specicially, relative symlinks, -that are checked into git. To allow you to move those around without -annoyance, git-annex can run as a post-commit hook. This way, you can `git mv` -a symlink to an annexed file, and as soon as you commit, it will be fixed -up. - -`git annex init` tries to set up a post-commit hook that is itself a symlink -back to git-annex. If you want to have your own shell script in the post-commit -hook, just make it call `git annex` with no parameters. git-annex will detect -when it's run from a git hook and do the necessary fixups. - -[[done]] diff --git a/doc/todo/symlink_git-annex_binaries_to___126____47__.local__47__bin_for_prebuilt_package.mdwn b/doc/todo/symlink_git-annex_binaries_to___126____47__.local__47__bin_for_prebuilt_package.mdwn deleted file mode 100644 index 627143924..000000000 --- a/doc/todo/symlink_git-annex_binaries_to___126____47__.local__47__bin_for_prebuilt_package.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -Instead of changing the `PATH`, it should be possible to symlink the binaries to the `~/.local/bin` directory. - -Here is a script I put on the prebuilt package (its basename is unimportant but it must be placed along with the git-annex script): - - #!/bin/sh - link="$(readlink "$0")" - base="$(cd "$(dirname "$0")"; cd "$(dirname "$link")"; echo "$PWD")" - name="$(basename "$0")" - exec "$base/$name" "$@" - -Symlink this script to `~/.local/bin/git-annex`, `~/.local/bin/git-annex-shell` and `~/.local/bin/git-annex-webapp`. on my system I have: - - lrwxrwxrwx. 1 mildred mildred 36 Dec 13 12:12 git-annex -> ../opt/git-annex.linux/run-git-annex - lrwxrwxrwx. 1 mildred mildred 36 Dec 13 12:12 git-annex-shell -> ../opt/git-annex.linux/run-git-annex - lrwxrwxrwx. 1 mildred mildred 36 Dec 13 12:12 git-annex-webapp -> ../opt/git-annex.linux/run-git-annex - -The script will detect the installation directory using `readlink`. Both absolute and relative links works. Then it starts the correct script depending on the basename of the link. - -It should be possible to link the `git-annex`, `git-annex-webapp` and `git-annex-shell` scripts instead if they used `readlink` to find out the location of the prebuilt package. - -> I've made the scripts look at readlink, so [[done]]. -> --[[Joey]] diff --git a/doc/todo/untracked_remotes.mdwn b/doc/todo/untracked_remotes.mdwn deleted file mode 100644 index f538c7560..000000000 --- a/doc/todo/untracked_remotes.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -Seems that a fairly common desire in some use cases is to be able to make a -clone of a repository and be able to get files, without updating the -location tracking information. (And without even recording a uuid in the -remote.log.) Use cases include wanting to have temporary -clones without cluttering history, and centralized development where the -developers don't care to know about one-another's systems. - -It seems that such an untracked repository would need to automatically -consider itself untrusted. Is that enough to avoid losing data? - -> [[done]]; set remote.<name>.annex-readonly=true to prevent -> git-annex from pushing changes to the remote, or modifying the contents -> of the remote in any way. -> -> Note that I am intentionally not making this feature be about security. -> The remote can still tell if you're connecting to it, and indeed if it -> really wants to, and git-annex-shell is being used on the remote, it can -> determine your local repository's uuid. -> -> This allows for some complicated setups. For example, a public repository -> P can be a readonly remote of a clone on your laptop L, and L in turn has -> another, non-readonly remote D on a removable drive. This allows L and D -> to keep track of which files one-another have, without leaking this info -> to P. But note that if L adds P as a remote, it also has to mark it -> readonly, to avoid leaking data. -> -> --[[Joey]] diff --git a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment b/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment deleted file mode 100644 index bab26dc10..000000000 --- a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2014-01-01T21:32:56Z" - content=""" -Such a class of repositories would be very useful, indeed. - -A good name would probably be, in descending order: - -* ephemeral -* volatile -* transient -* fleeting - -It would be somewhere in between 'untrusted' and 'dead'. - -I can see two approaches working nicely, here: - -1. Local location log -2. Local location log in another branch / directory -3. No location log - -In the first case, location data would be added to the local location log, but any `git annex sync` or similar would parse the location log and strip out all mentions of the UUID in question. -This would be somewhat slower when synching, but would ensure that all operations which rely on local logs operate normally. - -In the second case, location data would be kept in a different location. -This would have the benefit of a clean separation and quicker merges, but induces overhead for lookups. -On the other hand, if those lookups are wrapped cleanly, only those functions would need to know about the different locations. - -In the last case, no local logs would be kept. - - -All in all, I think I would prefer the first option. - -The one thing that's hard/impossible by design is for other remotes to strip out the data. -As the repository would not be known to other remotes, they would simply continue the carry the data. -This can be worked around by setting the repository to "dead". -Ephemeral repositories would not correct "dead" info about themselves; they _would_ start behaving normally once set to trusted, semit-trusted, or untrusted, though. - - -Richard -"""]] diff --git a/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment b/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment deleted file mode 100644 index 1233a4379..000000000 --- a/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 2" - date="2014-01-01T22:30:07Z" - content=""" -3. doesn't work because there could be a special remote or another repository that an untracked repo communicates with (forming their own little subnet hidden from the main network), and so it needs to use remote.log and location tracking for that in the usual way. - -It might suffice to make `git annex sync` not push any branches from an untracked repo to its remotes. Its git-annex branch would thus diverge locally, but still contain the global state. There is probably a way to make git refuse to push a branch (at least when naively running `git push` -- I never completely understand how git tracking branches work). Or a pre-push hook could be installed to block an accidential push. - -The uuid of an untracked repo would also leak out in the remoteuuid parameter passed to git-annex-shell. That may not matter (as long as it's not used to update the location log, which it doesn't seem to be; the remoteuuid is only used for displaying transfers AFAICS). - ----- - -I'm still be worried about handling numcopies though. Suppose an untracked repo runs `git annex drop --from publicrepo`. We don't want to end up with the numcopies satisfied by the untracked repo and the other remotes that only it can access, because this would seem to make a file vanish from the public network's perspective. `git annex move` is even worse a problem, and even setting the untracked repo to untrusted or dead wouldn't help if the only copies of files are moved to it. - -It seems that an untracked repo should refuse to remove content from the repositories it's \"hiding\" from, and if it's never going to git push to it, there is also no point in uploading annexed objects to it either. So, perhaps make `git.<remote>.annex-read-only = true` be used to configure a remote as read-only, and refuse to push any git branches to a read-only remote, as well as prohibit storekey and removekey being used with any read-only remote (which might be a special remote). -"""]] diff --git a/doc/todo/untracked_remotes/comment_3_0d07c5bc8d42f35351c11411eaca88df._comment b/doc/todo/untracked_remotes/comment_3_0d07c5bc8d42f35351c11411eaca88df._comment deleted file mode 100644 index 946eeaa6c..000000000 --- a/doc/todo/untracked_remotes/comment_3_0d07c5bc8d42f35351c11411eaca88df._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 3" - date="2014-01-02T00:26:14Z" - content=""" -Regarding 1.: If two untracked repositories are talking to each other, they should not be tracked at all, so I don't see any issue there. -If an untracked repository communicates with a tracked one, the untracked one should still send updates for the tracked one when synching. -The solution might really simply be a specific untracked location log distinct from the rest. -This would even allow merging changes back into the main log if the user decides to track a repository after all. - -Regarding pushing to tracking branches: This behavior will change soon and you can override it; see the manpage for `git-config(1)` at push.default. - -Location leaks could be solved by passing `00000000-0000-0000-0000-000000000002` as UUID. -Using that UUID might also be the solution for all untracked repos as it's trivial to special case for this, but: -* What happens when you switch a known repo to untracked? What happens to its UUID in various logs? Maybe introduce a specific discard log which tries to get rid of all data concerning those UUIDs? -* What happens when you switch a repo from untracked to tracked? Simply generate (reactivate?) a UUID and switch all local occurences of `00000000-0000-0000-0000-000000000002` to the new UUID? - -`git annex drop --from publicrepo` is not allowed to take local copies into account to satisfy `numcopies`, simple as that. -IMO, this is the only valid approach, as that mirrors the global view from all other repos. -For all intents and purposes, an untracked repo does not exist. - - -The complement, a read-only repo, would also be very useful. -Such a repo would hold data, but it would never accept location data of anywhere besides itself and the web remote. - - -Richard -"""]] diff --git a/doc/todo/untracked_remotes/comment_4_75ae13c2135a2951b2af548139cb25cd._comment b/doc/todo/untracked_remotes/comment_4_75ae13c2135a2951b2af548139cb25cd._comment deleted file mode 100644 index fd9397531..000000000 --- a/doc/todo/untracked_remotes/comment_4_75ae13c2135a2951b2af548139cb25cd._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 4" - date="2014-01-02T01:15:40Z" - content=""" -Another use case of read-only repos: - -Instead of merging pull requests or anything, with git-annex, it makes most sense to simply set up the other party as a remote and `git annex sync`. -This will attempt to push to the other remote. - -In this specific case: - - % git annex sync - commit - ok - pull origin - ok - pull greggrossmeier - ok - push origin - Counting objects: 113, done. - Delta compression using up to 4 threads. - Compressing objects: 100% (84/84), done. - Writing objects: 100% (98/98), 25.16 KiB | 0 bytes/s, done. - Total 98 (delta 17), reused 1 (delta 0) - To git@github.com:RichiH/conference_proceedings.git - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master - ok - push greggrossmeier - Username for 'https://github.com': - Password for 'https://github.com': - remote: Anonymous access to greggrossmeier/conference_proceedings.git denied. - fatal: Authentication failed for 'https://github.com/greggrossmeier/conference_proceedings.git/' - Username for 'https://github.com': - Password for 'https://github.com': - - Pushing to greggrossmeier failed. - - (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config) - failed - git-annex: sync: 1 failed - % - -"""]] diff --git a/doc/todo/use_cp_reflink.mdwn b/doc/todo/use_cp_reflink.mdwn deleted file mode 100644 index 39518abf1..000000000 --- a/doc/todo/use_cp_reflink.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -The unlock command needs to copy a file, and it would be great to use this: - cp --reflink=auto src dst - -O(1) overhead on BTRFS. Needs coreutils 7.6; and remember that git-annex -may be used on systems without coreutils.. - -[[done]] diff --git a/doc/todo/using_url_backend.mdwn b/doc/todo/using_url_backend.mdwn deleted file mode 100644 index 1f3cd5628..000000000 --- a/doc/todo/using_url_backend.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -There is no way to `git annex add` a file using the URL [[backend|backends]]. - -For now, we have to manually make the symlink. Something like this: - - ln -s .git/annex/URL:http:%%www.example.com%foo.tar.gz - -Note the escaping of slashes. - -A `git annex register <url>` command could do this.. - -[[done]] diff --git a/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn b/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn deleted file mode 100644 index 6bbfd7a4d..000000000 --- a/doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -It'd be useful to be able to see what `git annex drop` would do *before* asking it to drop any files. - -For example, I just set up my preferred contents expressions, and I don't know if I got them right. Before dropping anything from this repo, it'd be nice to check what would happen. I know git annex drop will only drop files that are above their minimum numcopies, but I'd still like to avoid heavyweight copying in case I got my preferred contents expressions wrong. - -> [[done]]; added --want-get and --want-drop. --[[Joey]] diff --git a/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_1_20ecfa8ffa52c238d21b904076ac69a2._comment b/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_1_20ecfa8ffa52c238d21b904076ac69a2._comment deleted file mode 100644 index 098d399e3..000000000 --- a/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_1_20ecfa8ffa52c238d21b904076ac69a2._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 1" - date="2013-10-28T17:11:04Z" - content=""" -It would be nice, but it adds quite a lot of complexity to have a --dry-run, and if I add it to just drop, the next bug is going to ask for get to have it.. - -I feel that the right approach is to add a --wanted, which could then be used with find to find files that are and are not wanted, according to the preferred content settings. To see what it would want to get: `git annex find --wanted --not --in .` To see what it would want to drop: `git annex find --not --wanted --in .` -"""]] diff --git a/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment b/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment deleted file mode 100644 index 3f1102985..000000000 --- a/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnWwEEA3CurHkBjIYaJsJzFc4jtY2SCkrQ" - nickname="Diego" - subject="comment 2" - date="2013-10-29T00:28:51Z" - content=""" -That makes sense, and thanks for adding this feature so quickly! -"""]] diff --git a/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp.mdwn b/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp.mdwn deleted file mode 100644 index 36e936e54..000000000 --- a/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -I would like to be able to set 'annex-ignore' for remote servers through the webapp. -Maybe a checkbox beneath "Syncing enabled" with something like "Also sync content" that it's checked by default? - -> Closing per my comment. [[done]] --[[Joey]] diff --git a/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp/comment_1_b3b5c12f89a0a6a91d681c67e2217199._comment b/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp/comment_1_b3b5c12f89a0a6a91d681c67e2217199._comment deleted file mode 100644 index b864a6b63..000000000 --- a/doc/todo/whislist:_allow_setting_annex-ignore_from_the_webapp/comment_1_b3b5c12f89a0a6a91d681c67e2217199._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="216.145.95.162" - subject="comment 1" - date="2014-05-19T17:09:16Z" - content=""" -This feels too complicated for the webapp. Especially because annex-ignore is intended to be used when the remote repository does not have git-annex-shell installed, so cannot contain any content. Which should be automatically detected when the webapp is used to set up a repository (or for that matter, when a repository is set up at the command line). -"""]] diff --git a/doc/todo/wishlist:_Add_to_Android_version_to_Google_Play.mdwn b/doc/todo/wishlist:_Add_to_Android_version_to_Google_Play.mdwn deleted file mode 100644 index f9016fb4d..000000000 --- a/doc/todo/wishlist:_Add_to_Android_version_to_Google_Play.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -If possible a frequently updated daily build in separate package for those more adventurous of us. - -It would make installing and testing much easier and no need to change configuration settings to allow untrusted source. - -> While it's vaid to wish that someone might put the apk into Google Play, -> I a) don't feel it's ready b) don't know if I want to go through -> the rigamarole required to use that service and c) don't feel this -> bug tracker is an appropriate place to track what is effectively a -> nontechnical request. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_An_--all_option_for_dropunused.mdwn b/doc/todo/wishlist:_An_--all_option_for_dropunused.mdwn deleted file mode 100644 index bd35c0e55..000000000 --- a/doc/todo/wishlist:_An_--all_option_for_dropunused.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Cleaning out a repository is presently a fairly manual process. Am I missing a UI trick? "dropunsed" with no arguments prints nothing at all; I think in that case it should display the list of what could be dropped. - -> [[done]]; comments seem satisfactory and I see no reason to complicate -> dropunused to output something unused already outputs. --[[Joey]] diff --git a/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_1_d8726d108b3b40116b4ec3c9935f2dff._comment b/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_1_d8726d108b3b40116b4ec3c9935f2dff._comment deleted file mode 100644 index 6c728a5d0..000000000 --- a/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_1_d8726d108b3b40116b4ec3c9935f2dff._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.23" - subject="comment 1" - date="2012-10-22T15:35:30Z" - content=""" -`git annex unused` prints the list -"""]] diff --git a/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_2_578248f7686ba2d80d7dc8b17c0cdf52._comment b/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_2_578248f7686ba2d80d7dc8b17c0cdf52._comment deleted file mode 100644 index a87a367d6..000000000 --- a/doc/todo/wishlist:_An_--all_option_for_dropunused/comment_2_578248f7686ba2d80d7dc8b17c0cdf52._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://hands.com/~phil/" - nickname="hands" - subject="and you can specify ranges to dropunused" - date="2012-11-02T09:07:48Z" - content=""" -so having run: - - git annex unused - -you can then run: - - git annex dropunused 1-10000 - -or whatever, and it deletes the items in that range from the most recent <tt>unused</tt> invocation -"""]] diff --git a/doc/todo/wishlist:_An_option_like_--git-dir.mdwn b/doc/todo/wishlist:_An_option_like_--git-dir.mdwn deleted file mode 100644 index 0582d9892..000000000 --- a/doc/todo/wishlist:_An_option_like_--git-dir.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I'm currently integrating git-annex support into a filesystem synchronization tool that I use, and I have a use case where I'd like to run "git annex sync' on a local directory, and then automatically ssh over to remote hosts and run "git annex sync" in the related annex on that remote host. However, while I can easily "cd" on the local, there is no really easy way to "cd" on the remote without a hack. - -If I could say: git annex --annex-dir=PATH sync, where PATH is the annex directory, it would solve all my problems, and would also provide a nice correlation to the --git-dir option used by most Git commands. The basic idea is that I shouldn't have to be IN the directory to run git-annex commands, I should be able to tell git-annex which directory to apply its commands to. - -> AFAIK this is fully supported for some time, so [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_An_option_like_--git-dir/comment_1_5d877d90b8bdf21d4b8649744d229efd._comment b/doc/todo/wishlist:_An_option_like_--git-dir/comment_1_5d877d90b8bdf21d4b8649744d229efd._comment deleted file mode 100644 index 8e7c3c03e..000000000 --- a/doc/todo/wishlist:_An_option_like_--git-dir/comment_1_5d877d90b8bdf21d4b8649744d229efd._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" - nickname="Justin" - subject="What about..." - date="2012-10-16T16:43:29Z" - content=""" - ssh remotehost \"cd /path/to/annex && git annex sync\" -"""]] diff --git a/doc/todo/wishlist:_An_option_like_--git-dir/comment_2_462264821cbc48a433330cbf7ec6044d._comment b/doc/todo/wishlist:_An_option_like_--git-dir/comment_2_462264821cbc48a433330cbf7ec6044d._comment deleted file mode 100644 index 980658dc6..000000000 --- a/doc/todo/wishlist:_An_option_like_--git-dir/comment_2_462264821cbc48a433330cbf7ec6044d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="2001:4978:f:21a::2" - subject="comment 2" - date="2012-10-17T18:31:58Z" - content=""" -You can use `GIT_DIR`. It would not be hard to add a --git-dir option, the only catch is how to communicate that state on to where it constructs its git repository data structure. (I suppose it could just set GIT_DIR..) -"""]] diff --git a/doc/todo/wishlist:_An_option_like_--git-dir/comment_3_0c3709b07a0a1091ceeee73b69e0f7ac._comment b/doc/todo/wishlist:_An_option_like_--git-dir/comment_3_0c3709b07a0a1091ceeee73b69e0f7ac._comment deleted file mode 100644 index a76c42d9d..000000000 --- a/doc/todo/wishlist:_An_option_like_--git-dir/comment_3_0c3709b07a0a1091ceeee73b69e0f7ac._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89" - nickname="John" - subject="Response" - date="2012-10-20T05:21:13Z" - content=""" -@Justin If you have full shell access on the remote your solution works fine, but not if git-annex is the only binary you are allowed to execute. -"""]] diff --git a/doc/todo/wishlist:_GnuPG_options.mdwn b/doc/todo/wishlist:_GnuPG_options.mdwn deleted file mode 100644 index 2cadf8213..000000000 --- a/doc/todo/wishlist:_GnuPG_options.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[Maybe I should have extented [[wishlist:_simpler_gpg_usage/]], but I thought I'd make my own since it's perhaps too old.] - -I second Justin and [[his idea|wishlist:_simpler_gpg_usage/#comment-e120f8ede0d4cffce17cbf84564211c1]] of having per-remote GnuPG options. I'd even go one step further, and propose the option in the <tt>.gitattributes</tt> file. Indeed by default GnuPG compresses the data before encryption, which doesn't make a lot of sense for git-annex (in my use-case at least); My work-around to save this waste of CPU cycles was to customize my <tt>gpg.conf</tt>, but it's somewhat dirty since I do want to use compression in general. - -Here is how I envision the <tt>.git/config</tt>: -<pre> <code>[annex] - gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo none -</code></pre> - -And compression could be enabled on say, text files, with a suitable wildcard in the <tt>.gitattributes</tt> file. -<pre> <code>*.txt annex.gnupg-options="--s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib" -</code></pre> - -This is something I could probably hack on if you think it'd be a worthwhile option ;-) - -> Done, and [[done]]! --[[Joey]] diff --git a/doc/todo/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment b/doc/todo/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment deleted file mode 100644 index b756eccad..000000000 --- a/doc/todo/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 1" - date="2013-03-09T01:54:30Z" - content=""" -I'd be happy to apply a patch implementing annex.gnupg-options and/or per-remote remote.annex-gnupg-options, and I don't think it would be very hard to do. - -The gitattributes thing would be harder to do efficiently, and seems overkill. - - -"""]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size.mdwn b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size.mdwn deleted file mode 100644 index 12688951d..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -When using SSH remote repository, git-annex uses rsync to download or upload files one at a time. I would like to have a preview of the overall transfer size so that I can estimate the transfer duration. - -This could be done as an option of get, move or copy, or as a separated command. - -If part of get, move or copy, git-annex could print how much has been done or how much left between every files. - -Thanks. - -> [[done]]; `git-annex status .` seems to cover the requested use case. -> --[[Joey]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment deleted file mode 100644 index 4a59f37f1..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.193" - subject="comment 1" - date="2013-06-25T17:26:25Z" - content=""" -git-annex is designed to work with really large trees of files, and so it processes files one at a time in a stream. To get an overall estimate of the size, it would need to traverse the whole directory to get the total, and then traverse it again to perform the transfer. This would make no-op transfers take twice as long, which is why I'm unlikely to implement it. -"""]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_29a154699339bf040af0ee8aa24034f1._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_29a154699339bf040af0ee8aa24034f1._comment deleted file mode 100644 index 9f0c04017..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_29a154699339bf040af0ee8aa24034f1._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnHRhCe3qwVKQ8_NOGGSYJnAMW6FFyKbOc" - nickname="Holger" - subject="comment 3" - date="2013-07-02T04:05:06Z" - content=""" -What do you think of the following simpler variant: - - % git annex size myfile1.zip - myfile1.zip is 1329 MB - % git annex size mydir/ - mydir contains 2803 files totaling 328 GB. - -If you're worried about running over the tree twice, it may be a good idea to store the size of a subtree along with the other metadata. -"""]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_8f7e1c4a5c714cbd719ee170354d79fa._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_8f7e1c4a5c714cbd719ee170354d79fa._comment deleted file mode 100644 index fa9fdfb56..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_3_8f7e1c4a5c714cbd719ee170354d79fa._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.193" - subject="comment 3" - date="2013-07-02T17:04:47Z" - content=""" -You can get info like that by running `git annex status .` - -This can also be used to find out how big a download is before starting it. For example, to find all files that are not present locally before running git-annex get: - -`git annex status . --not --in here` -"""]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_4_c7335f757e5546aa841cab38fffe7605._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_4_c7335f757e5546aa841cab38fffe7605._comment deleted file mode 100644 index b9212a24d..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_4_c7335f757e5546aa841cab38fffe7605._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnHRhCe3qwVKQ8_NOGGSYJnAMW6FFyKbOc" - nickname="Holger" - subject="comment 4" - date="2013-07-02T21:09:03Z" - content=""" -That's so cool, thanks! - -Do you think it'd be a major change to the repository format if the size of any directory was stored there so that this kind of status lookup becomes a constant time operation? The two most important operations are probably: - -* The total size of a directory, counting only files present here -* The total size of a directory, counting all files present at any location - -Of course, if the above two were constant time operations, you get --not here for free, too. - -To implement this, each node in the directory tree could have two additional 64 bit fields that hold the number of bytes in all files present anywhere (and this set of numbers is synchronized between all repositories), and the number of bytes in all files present here (only kept locally). This is only a small storage overhead (<16 MB if you have a million nodes) and suffices for repositories of size at most 2^64 bytes = 16 exabytes (probably more since most users will be ok with float accuracy). The numbers can be updated in logarithmic time every time a file changes. Instead of two numbers, it may not be that costly to store k numbers where k is the number of locations that a repository is connected to, since k is typically pretty small. - -The number of files can be stored in a similar way. -"""]] diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_5_d2a845354f23d07880612740cf99ddd4._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_5_d2a845354f23d07880612740cf99ddd4._comment deleted file mode 100644 index 7e160bebf..000000000 --- a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_5_d2a845354f23d07880612740cf99ddd4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnHRhCe3qwVKQ8_NOGGSYJnAMW6FFyKbOc" - nickname="Holger" - subject="comment 5" - date="2013-07-03T02:43:32Z" - content=""" -Btw, this would also provide a cheap test for whether we need to recurse into the folder in certain copy or get actions (e.g., if number of bytes present here equals number of bytes globally present, we don't need to recurse). -"""]] diff --git a/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command.mdwn b/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command.mdwn deleted file mode 100644 index cb170dbe4..000000000 --- a/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -Simple, when performing various git annex command over ssh, in particular a multi-file get, and using password authentication, git annex will prompt more than once for a user password. This makes batch updates very inconvenient. - -> I'd suggest using ssh-agent, or a passwordless ssh key. Possibly in -> combination with [[git-annex-shell]] if you want to lock down a -> particular ssh key to only being able to use git-annex and git-daemon. -> -> Combining multiple operations into a single ssh is on the todo list, but -> very far down it. --[[Joey]] - ->> OTOH, automatically running ssh in ControlMaster mode (and stopping it ->> at exit) would be useful and not hard thing for git-annex to do. ->> ->> It'd just need to set the appropriate config options, setting ->> ControlPath to a per-remote socket location that includes git-annex's ->> pid. Then at shutdown, run `ssh -O exit` on each such socket. ->> ->> Complicated slightly by not doing this if the user has already set up ->> more broad ssh connection caching. ->> ->> [[done]]! --[[Joey]] - ---- - -Slightly more elaborate design for using ssh connection caching: - -* Per-uuid ssh socket in `.git/annex/ssh/user@host.socket` -* Can be shared among concurrent git-annex processes as well as ssh - invocations inside the current git-annex. -* Also a lock file, `.git/annex/ssh/user@host.lock`. - Open and take shared lock before running ssh; store lock in lock pool. - (Not locking socket directly, because ssh might want to.) -* Run ssh like: `ssh -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes user@host` -* At shutdown, enumerate all existing sockets, and on each: - 1. Drop any shared lock. - 2. Attempt to take an exclusive lock (non-blocking). - 3. `ssh -q -S .git/annex/ssh/user@host.socket -o ControlMaster=auto -o ControlPersist=yes -O stop user@host` - (Will exit nonzero if ssh is not running on that socket.) - 4. And then remove the socket and the lock file. -* Do same *at startup*. Why? In case an old git-annex was interrupted - and left behind a ssh. May have moved to a different network - in the meantime, etc, and be stalled waiting for a response from the - network, or talking to the wrong interface or something. - (Ie, the reason why I don't use ssh connection caching by default.) -* User should be able to override this, to use their own preferred - connection caching setup. `annex.sshcaching=false` diff --git a/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command/comment_1_3f9c0d08932c2ede61c802a91261a1f7._comment b/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command/comment_1_3f9c0d08932c2ede61c802a91261a1f7._comment deleted file mode 100644 index 2801d8e68..000000000 --- a/doc/todo/wishlist:_Prevent_repeated_password_prompts_for_one_command/comment_1_3f9c0d08932c2ede61c802a91261a1f7._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-05-06T18:30:02Z" - content=""" -Unless you are forced to use a password, you should really be using a ssh key. - - ssh-keygen - #put local .ssh/id_?sa.pub into remote .ssh/authorized_keys (which needs to be chmod 600) - ssh-add - git annex whatever - -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates.mdwn b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates.mdwn deleted file mode 100644 index 933653578..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -(Hi, this is paulproteus@debian, AKA Asheesh). - -I've been enjoying using git-annex to archive my data. - -It's great that, by using git-annex and the SHA1 backend, I get a space-saving kind of deduplication through the symbolic links. - -I'm looking for the ability to filter files, before they get added to the annex, so that I don't add new files whose content is already in the annex.look That would help me in terms of personal file organization. - -It seems there is not, so this is a wishlist bug filed so that maybe such a thing might exist. What I would really like to do is: - -* $ git annex add --no-add-if-already-present . -* $ git commit -m "Slurping in some photos I found on my old laptop hard drive" - -And then I'd do something like: - -* $ git clean -f - -to remove the files that didn't get annexed in this run. That way, only one filename would ever point to a particular SHA1. - -I want this because I have copies of various of mine (photos, in particular) scattered across various hard disks. If this feature existed, I could comfortably toss them all into one git annex that grew, bit by bit, to store all of these files exactly once. - -(I would be even happier for "git annex add --unlink-duplicates .") - -(Another way to do this would be to "git annex add" them all, and then use a "git annex remove-duplicates" that could prompt me about which files are duplicates of each other, and then I could pipe that command's output into xargs git rm.) - -(As I write this, I realize it's possible to parse the destination of the symlink in a way that does this..) - -> [[done]]; see [[tips/finding_duplicate_files]] --[[Joey]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_10_d78d79fb2f3713aa69f45d2691cf8dfe._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_10_d78d79fb2f3713aa69f45d2691cf8dfe._comment deleted file mode 100644 index 5dbb66cf6..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_10_d78d79fb2f3713aa69f45d2691cf8dfe._comment +++ /dev/null @@ -1,68 +0,0 @@ -[[!comment format=mdwn - username="http://adamspiers.myopenid.com/" - nickname="Adam" - subject="comment 10" - date="2011-12-23T17:22:11Z" - content=""" -> Your perl script is not O(n). Inserting into perl hash tables has -> overhead of minimum O(n log n). - -What's your source for this assertion? I would expect an amortized -average of `O(1)` per insertion, i.e. `O(n)` for full population. - -> Not counting the overhead of resizing hash tables, -> the grevious slowdown if the bucket size is overcome by data (it -> probably falls back to a linked list or something then), and the -> overhead of traversing the hash tables to get data out. - -None of which necessarily change the algorithmic complexity. However -real benchmarks are far more useful here than complexity analysis, and -[the dangers of premature optimization](http://c2.com/cgi/wiki?PrematureOptimization) -should not be forgotten. - -> Your memory size calculations ignore the overhead of a hash table or -> other data structure to store the data in, which will tend to be -> more than the actual data size it's storing. I estimate your 50 -> million number is off by at least one order of magnitude, and more -> likely two; - -Sure, I was aware of that, but my point still stands. Even 500k keys -per 1GB of RAM does not sound expensive to me. - -> in any case I don't want git-annex to use 1 gb of ram. - -Why not? What's the maximum it should use? 512MB? 256MB? -32MB? I don't see the sense in the author of a program -dictating thresholds which are entirely dependent on the context -in which the program is *run*, not the context in which it's *written*. -That's why systems have files such as `/etc/security/limits.conf`. - -You said you want git-annex to scale to enormous repositories. If you -impose an arbitrary memory restriction such as the above, that means -avoiding implementing *any* kind of functionality which requires `O(n)` -memory or worse. Isn't it reasonable to assume that many users use -git-annex on repositories which are *not* enormous? Even when they do -work with enormous repositories, just like with any other program, -they would naturally expect certain operations to take longer or -become impractical without sufficient RAM. That's why I say that this -restriction amounts to throwing out the baby with the bathwater. -It just means that those who need the functionality would have to -reimplement it themselves, assuming they are able, which is likely -to result in more wheel reinventions. I've already shared -[my implementation](https://github.com/aspiers/git-config/blob/master/bin/git-annex-finddups) -but how many people are likely to find it, let alone get it working? - -> Little known fact: sort(1) will use a temp file as a buffer if too -> much memory is needed to hold the data to sort. - -Interesting. Presumably you are referring to some undocumented -behaviour, rather than `--batch-size` which only applies when merging -multiple files, and not when only sorting STDIN. - -> It's also written in the most efficient language possible and has -> been ruthlessly optimised for 30 years, so I would be very surprised -> if it was not the best choice. - -It's the best choice for sorting. But sorting purely to detect -duplicates is a dismally bad choice. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_11_4316d9d74312112dc4c823077af7febe._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_11_4316d9d74312112dc4c823077af7febe._comment deleted file mode 100644 index 286487eee..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_11_4316d9d74312112dc4c823077af7febe._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 11" - date="2011-12-23T17:52:21Z" - content=""" -I don't think that [[tips/finding_duplicate_files]] is hard to find, and the multiple different ways it shows to deal with the duplicate files shows the flexability of the unix pipeline approach. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_12_ed6d07f16a11c6eee7e3d5005e8e6fa3._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_12_ed6d07f16a11c6eee7e3d5005e8e6fa3._comment deleted file mode 100644 index 909beed83..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_12_ed6d07f16a11c6eee7e3d5005e8e6fa3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 12" - date="2011-12-23T18:02:24Z" - content=""" -BTW, sort -S '90%' benchmarks consistently 2x as fast as perl's hashes all the way up to 1 million files. Of course the pipeline approach allows you to swap in perl or whatever else is best for you at scale. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_1_fd213310ee548d8726791d2b02237fde._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_1_fd213310ee548d8726791d2b02237fde._comment deleted file mode 100644 index 094e4526e..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_1_fd213310ee548d8726791d2b02237fde._comment +++ /dev/null @@ -1,29 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-01-27T18:29:44Z" - content=""" -Hey Asheesh, I'm happy you're finding git-annex useful. - -So, there are two forms of duplication going on here. There's duplication of the content, and duplication of the filenames -pointing at that content. - -Duplication of the filenames is probably not a concern, although it's what I thought you were talking about at first. It's probably info worth recording that backup-2010/some_dir/foo and backup-2009/other_dir/foo are two names you've used for the same content in the past. If you really wanted to remove backup-2009/foo, you could do it by writing a script that looks at the basenames of the symlink targets and removes files that point to the same content as other files. - -Using SHA1 ensures that the same key is used for identical files, so generally avoids duplication of content. But if you have 2 disks with an identical file on each, and make them both into annexes, then git-annex will happily retain both -copies of the content, one per disk. It generally considers keeping copies of content a good thing. :) - -So, what if you want to remove the unnecessary copies? Well, there's a really simple way: - -<pre> -cd /media/usb-1 -git remote add other-disk /media/usb-0 -git annex add -git annex drop -</pre> - -This asks git-annex to add everything to the annex, but then remove any file contents that it can safely remove. What can it safely remove? Well, anything that it can verify is on another repository such as \"other-disk\"! So, this will happily drop any duplicated file contents, while leaving all the rest alone. - -In practice, you might not want to have all your old backup disks mounted at the same time and configured as remotes. Look into configuring [[trust]] to avoid needing do to that. If usb-0 is already a trusted disk, all you need is a simple \"git annex drop\" on usb-1. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_2_4394bde1c6fd44acae649baffe802775._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_2_4394bde1c6fd44acae649baffe802775._comment deleted file mode 100644 index 04d58a459..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_2_4394bde1c6fd44acae649baffe802775._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkjvjLHW9Omza7x1VEzIFQ8Z5honhRB90I" - nickname="Asheesh" - subject="I actually *do* want to avoid duplication of filenames" - date="2011-01-28T07:30:05Z" - content=""" -I really do want just one filename per file, at least for some cases. - -For my photos, there's no benefit to having a few filenames point to the same file. As I'm putting them all into the git-annex, that is a good time to remove the pure duplicates so that I don't e.g. see them twice when browsing the directory as a gallery. Also, I am uploading my photos to the web, and I want to avoid uploading the same photo (by content) twice. - -I hope that makes things clearer! - -For now I'm just doing this: - -* paulproteus@renaissance:/mnt/backups-terabyte/paulproteus/sd-card-from-2011-01-06/sd-cards/DCIM/100CANON $ for file in *; do hash=$(sha1sum \"$file\"); if ls /home/paulproteus/Photos/in-flickr/.git-annex | grep -q \"$hash\"; then echo already annexed ; else flickr_upload \"$file\" && mv \"$file\" \"/home/paulproteus/Photos/in-flickr/2011-01-28/from-some-nested-sd-card-bk\" && (cd /home/paulproteus/Photos/in-flickr/2011-01-28/from-some-nested-sd-card-bk && git annex add . && git commit -m ...) ; fi; done - -(Yeah, Flickr for my photos for now. I feel sad about betraying the principle of autonomo.us-ness.) -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_3_076cb22057583957d5179d8ba9004605._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_3_076cb22057583957d5179d8ba9004605._comment deleted file mode 100644 index d11119bc3..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_3_076cb22057583957d5179d8ba9004605._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkjvjLHW9Omza7x1VEzIFQ8Z5honhRB90I" - nickname="Asheesh" - subject="Duplication of the filenames is what I am concerned about" - date="2011-04-29T11:48:22Z" - content=""" -For what it's worth, yes, I want to actually forget I ever had the same file in the filesystem with a duplicated name. I'm not just aiming to clean up the disk's space usage; I'm also aiming to clean things up so that navigating the filesystem is easier. - -I can write my own script to do that based on the symlinks' target (and I wrote something along those lines), but I still think it'd be nicer if git-annex supported this use case. - -Perhaps: - -<pre>git annex drop --by-contents</pre> - -could let me remove a file from git-annex if the contents are available through a different name. (Right now, \"git annex drop\" requires the name *and* contents match.) - --- Asheesh. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_4_f120d1e83c1a447f2ecce302fc69cf74._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_4_f120d1e83c1a447f2ecce302fc69cf74._comment deleted file mode 100644 index a218ee3d5..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_4_f120d1e83c1a447f2ecce302fc69cf74._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="http://adamspiers.myopenid.com/" - nickname="Adam" - subject="List the duplicate filenames, then let the user decide what to do" - date="2011-12-22T12:31:29Z" - content=""" -I have the same use case as Asheesh but I want to be able to see which filenames point to the same objects and then decide which of the duplicates to drop myself. I think - - git annex drop --by-contents - -would be the wrong approach because how does git-annex know which ones to drop? There's too much potential for error. - -Instead it would be great to have something like - - git annex finddups - -While it's easy enough to knock up a bit of shell or Perl to achieve this, that relies on knowledge of the annex symlink structure, so I think really it belongs inside git-annex. - -If this command gave output similar to the excellent `fastdup` utility: - - Scanning for files... 672 files in 10.439 seconds - Comparing 2 sets of files... - - 2 files (70.71 MB/ea) - /home/adam/media/flat/tour/flat-tour.3gp - /home/adam/videos/tour.3gp - - Found 1 duplicate of 1 file (70.71 MB wasted) - Scanned 672 files (1.96 GB) in 11.415 seconds - -then you could do stuff like - - git annex finddups | grep /home/adam/media/flat | xargs rm - -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_5_5c30294b3c59fdebb1eef0ae5da4cd4f._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_5_5c30294b3c59fdebb1eef0ae5da4cd4f._comment deleted file mode 100644 index e48a4a9b3..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_5_5c30294b3c59fdebb1eef0ae5da4cd4f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://adamspiers.myopenid.com/" - nickname="Adam" - subject="Here's a Perl version" - date="2011-12-22T15:43:51Z" - content=""" -https://github.com/aspiers/git-config/blob/master/bin/git-annex-finddups - -but it would be better in git-annex itself ... -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_6_f24541ada1c86d755acba7e9fa7cff24._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_6_f24541ada1c86d755acba7e9fa7cff24._comment deleted file mode 100644 index 5d8ac8e61..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_6_f24541ada1c86d755acba7e9fa7cff24._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 6" - date="2011-12-22T16:39:24Z" - content=""" -My main concern with putting this in git-annex is that finding duplicates necessarily involves storing a list of every key and file in the repository, and git-annex is very carefully built to avoid things that require non-constant memory use, so that it can scale to very big repositories. (The only exception is the `unused` command, and reducing its memory usage is a continuing goal.) - -So I would rather come at this from a different angle.. like providing a way to output a list of files and their associated keys, which the user can then use in their own shell pipelines to find duplicate keys: - - git annex find --include '*' --format='${file} ${key}\n' | sort --key 2 | uniq --all-repeated --skip-fields=1 - -Which is implemented now! - -(Making that pipeline properly handle filenames with spaces is left as an exercise for the reader..) -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_7_c39f1bb7c61a89b238c61bee1c049767._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_7_c39f1bb7c61a89b238c61bee1c049767._comment deleted file mode 100644 index a33700280..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_7_c39f1bb7c61a89b238c61bee1c049767._comment +++ /dev/null @@ -1,54 +0,0 @@ -[[!comment format=mdwn - username="http://adamspiers.myopenid.com/" - nickname="Adam" - subject="comment 7" - date="2011-12-22T20:04:14Z" - content=""" -> My main concern with putting this in git-annex is that finding -> duplicates necessarily involves storing a list of every key and file -> in the repository - -Only if you want to search the *whole* repository for duplicates, and if -you do, then you're necessarily going to have to chew up memory in -some process anyway, so what difference whether it's git-annex or -(say) a Perl wrapper? - -> and git-annex is very carefully built to avoid things that require -> non-constant memory use, so that it can scale to very big -> repositories. - -That's a worthy goal, but if everything could be implemented with an -O(1) memory footprint then we'd be in much more pleasant world :-) -Even O(n) isn't that bad ... - -That aside, I like your `--format=\"%f %k\n\"` idea a lot. That opens -up the \"black box\" of `.git/annex/objects` and makes nice things -possible, as your pipeline already demonstrates. However, I'm not -sure why you think `git annex find | sort | uniq` would be more -efficient. Not only does the sort require the very thing you were -trying to avoid (i.e. the whole list in memory), but it's also -O(n log n) which is significantly slower than my O(n) Perl script -linked above. - -More considerations about this pipeline: - -* Doesn't it only include locally available files? Ideally it should - spot duplicates even when the backing blob is not available locally. -* What's the point of `--include '*'` ? Doesn't `git annex find` - with no arguments already include all files, modulo the requirement - above that they're locally available? -* Any user using this `git annex find | ...` approach is likely to - run up against its limitations sooner rather than later, because - they're already used to the plethora of options `find(1)` provides. - Rather than reinventing the wheel, is there some way `git annex find` - could harness the power of `find(1)` ? - -Those considerations aside, a combined approach would be to implement - - git annex find --format=... - -and then alter my Perl wrapper to `popen(2)` from that rather than using -`File::Find`. But I doubt you would want to ship Perl wrappers in the -distribution, so if you don't provide a Haskell equivalent then users -who can't code are left high and dry. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_8_221ed2e53420278072a6d879c6f251d1._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_8_221ed2e53420278072a6d879c6f251d1._comment deleted file mode 100644 index 5ac292afe..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_8_221ed2e53420278072a6d879c6f251d1._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://adamspiers.myopenid.com/" - nickname="Adam" - subject="How much memory would it actually use anyway?" - date="2011-12-22T20:15:22Z" - content=""" -Another thought - an SHA1 digest is 20 bytes. That means you can fit over 50 million keys into 1GB of RAM. Granted you also need memory to store the values (pathnames) which in many cases will be longer, and some users may also choose more expensive backends than SHA1 ... but even so, it seems to me that you are at risk of throwing the baby out with the bath water. -"""]] diff --git a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_9_aecfa896c97b9448f235bce18a40621d._comment b/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_9_aecfa896c97b9448f235bce18a40621d._comment deleted file mode 100644 index 82c6921eb..000000000 --- a/doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/comment_9_aecfa896c97b9448f235bce18a40621d._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 9" - date="2011-12-23T16:07:39Z" - content=""" -Adam, to answer a lot of points breifly.. - -* --include='*' makes find list files whether their contents are present or not -* Your perl script is not O(n). Inserting into perl hash tables has overhead of minimum O(n log n). Not counting the overhead of resizing hash tables, the grevious slowdown if the bucket size is overcome by data (it probably falls back to a linked list or something then), and the overhead of traversing the hash tables to get data out. -* I think that git-annex's set of file matching options is coming along nicely, and new ones can easily be added, so see no need to pull in unix find(1). -* Your memory size calculations ignore the overhead of a hash table or other data structure to store the data in, which will tend to be more than the actual data size it's storing. I estimate your 50 million number is off by at least one order of magnitude, and more likely two; in any case I don't want git-annex to use 1 gb of ram. -* Little known fact: sort(1) will use a temp file as a buffer if too much memory is needed to hold the data to sort. It's also written in the most efficient language possible and has been ruthlessly optimised for 30 years, so I would be very surprised if it was not the best choice. -"""]] diff --git a/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn b/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn deleted file mode 100644 index f65a95f45..000000000 --- a/doc/todo/wishlist:_Tell_git_annex___40__assistant__41___which_files___40__not__41___to_annex_via_.gitattributes.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Title says it all. - -It would be nice if I could tell git annex (assistant) which files (not) to annex (automatically). - -[[!tag /design/assistant]] - -> [[done]]; use `annex.largefiles` git config to configure criteria for -> which files should be annexed. The rest will be added to git as normal -> files. --[[Joey]] diff --git a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes.mdwn b/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes.mdwn deleted file mode 100644 index a04af05b4..000000000 --- a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -Hello, - -i'm in the process of managing my music collection with git-annex. The initial "git annex add" using the sha1 banckend is quite long an i was wondering that it could be nice to launch multiple "sha1sum" processes in parallel to speed up things. - -Anyway, thanks for this wonderful piece of software. - -Jean-Baptiste - -> closing as dup of [[parallel possibilities]] (also see comments below) -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_1_85b14478411a33e6186a64bd41f0910d._comment b/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_1_85b14478411a33e6186a64bd41f0910d._comment deleted file mode 100644 index 2364b7fb8..000000000 --- a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_1_85b14478411a33e6186a64bd41f0910d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-02-25T19:12:42Z" - content=""" -I'd expect the checksumming to be disk bound, not CPU bound, on most systems. - -I suggest you start off on the WORM backend, and then you can run a job later to [[migrate|walkthrough#index14h2]] to the SHA1 backend. -"""]] diff --git a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_2_82e857f463cfdf73c70f6c0a9f9a31d6._comment b/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_2_82e857f463cfdf73c70f6c0a9f9a31d6._comment deleted file mode 100644 index 9b8240658..000000000 --- a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_2_82e857f463cfdf73c70f6c0a9f9a31d6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 2" - date="2011-02-25T19:54:28Z" - content=""" -But, see [[todo/parallel_possibilities]] -"""]] diff --git a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_3_8af85eba7472d9025c6fae4f03e3ad75._comment b/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_3_8af85eba7472d9025c6fae4f03e3ad75._comment deleted file mode 100644 index ee769f0dd..000000000 --- a/doc/todo/wishlist:___34__git_annex_add__34___multiple_processes/comment_3_8af85eba7472d9025c6fae4f03e3ad75._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="jbd" - ip="89.158.228.148" - subject="comment 3" - date="2011-02-26T10:26:12Z" - content=""" -Thank your for your answer and the link ! -"""]] diff --git a/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies.mdwn b/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies.mdwn deleted file mode 100644 index 67a7e13e1..000000000 --- a/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -As the title says, I would like to see an option where git-annex verifies -that all checksums are OK but not that the required number of copies or -other possible metrics are fulfilled. - --- RichiH - -> --numcopies is provided for times when you want to temporarily override -> annex.numcopies. So, `git annex fsck --numcopies=0` -> -> I don't see any reason to want to disable the other checks and fixups -> fsck does (of bad location log data, for example). So, [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies/comment_1_6bcf067e4860bdfeb1d7b9fd1702a43a._comment b/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies/comment_1_6bcf067e4860bdfeb1d7b9fd1702a43a._comment deleted file mode 100644 index c8f40caf7..000000000 --- a/doc/todo/wishlist:___96__git_annex_fsck_--checksums__96___--_verify_checksums_but_disregard_annex.numcopies/comment_1_6bcf067e4860bdfeb1d7b9fd1702a43a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2013-07-10T23:09:31Z" - content=""" -As a side note, --numcopies was broken, but it's been fixed with 4.20130709. -"""]] diff --git a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex.mdwn b/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex.mdwn deleted file mode 100644 index cd679485b..000000000 --- a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -`git annex import` would copy data over from external places into the annex. It would be run from within the annex and in the target location where the files need to end up. - -Two basic modes of operation: - -* If run on a normal directory, e.g. an SD card, it would simply copy over and `git annex add $newstuff` - -* If run on another indirect annex, it would copy over the symlinks, copy over the object data, verify that the checksums are OK and add to the annex - -An optional `git annex import --copy-only` would copy over and verify the data, but not yet add it. That would allow the user to import into a decent data structure. If run on non-annexed data, `git annex import --copy-only` would ideally calculate checksums and create symlinks already; thus ensuring data integrity as early as possible. - --- RichiH - -> [[done]] --[[Joey]] in 2012 diff --git a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_1_b9fd1bfaf9a3d238fdb7bc9c2d75fe5f._comment b/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_1_b9fd1bfaf9a3d238fdb7bc9c2d75fe5f._comment deleted file mode 100644 index ff9030c99..000000000 --- a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_1_b9fd1bfaf9a3d238fdb7bc9c2d75fe5f._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.153.254.222" - subject="comment 1" - date="2013-07-07T18:09:20Z" - content=""" -This is such a good idea that I went into the time machine and arranged for it to be implemented in June 2012: - -<pre> - import [path ...] - Moves files from somewhere outside the git work‐ - ing copy, and adds them to the annex. Individual - files to import can be specified. If a direc‐ - tory is specified, all files in it are imported, - and any subdirectory structure inside it is pre‐ - served. - - git annex import /media/camera/DCIM/ -</pre> - -I don't see much use for `--copy-only` though. so did not implement it them (also I needed to spend some of my time at the race track). It seems to me that using `--copy-only` as you describe it would do everything except for add the files to git. You can get the same behavior by using `git annex import`, which only stages the new files but does not commit them, and then moving files around and running `git annex add` on them, followed by committing. -"""]] diff --git a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_2_56f6972413c6f0d9f414245b6f4d27b9._comment b/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_2_56f6972413c6f0d9f414245b6f4d27b9._comment deleted file mode 100644 index ccdf2e704..000000000 --- a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_2_56f6972413c6f0d9f414245b6f4d27b9._comment +++ /dev/null @@ -1,62 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2013-07-10T23:25:52Z" - content=""" -Ugh, learn to read, etc... - -It's not possible to import from other annexes, though. Importing just the files from an indirect repo does nothing: - - ~/test-annex--foo % git annex status - supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL - supported remote types: git S3 bup directory rsync web webdav glacier hook - repository mode: indirect - trusted repositories: 0 - semitrusted repositories: 2 - 00000000-0000-0000-0000-000000000001 -- web - 8105410b-d8ca-4de4-bb6a-91b9772250dc -- here (richih@adamantium:~/test-annex--foo) - untrusted repositories: 0 - transfers in progress: none - available local disk space: 52 gigabytes (+1 megabyte reserved) - local annex keys: 1 - local annex size: 4 bytes - known annex keys: 1 - known annex size: 4 bytes - bloom filter size: 16 mebibytes (0% full) - backend usage: - SHA256E: 2 - ~/test-annex--foo % ls -l - total 4 - lrwxrwxrwx 1 richih richih 178 Jul 11 01:21 bar -> .git/annex/objects/g7/9v/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 - ~/test-annex--foo % cd ../test-annex - ~/test-annex % git annex status - supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL - supported remote types: git S3 bup directory rsync web webdav glacier hook - repository mode: indirect - trusted repositories: (merging synced/git-annex into git-annex...) - 0 - semitrusted repositories: 3 - 00000000-0000-0000-0000-000000000001 -- web - 7c50da8c-dc76-4b4a-b46d-8dd16385691a -- here (richih@adamantium:~/test-annex) - d4104a13-a2eb-4f5c-ba54-990ece5c81df -- richih@adamantium:~/test-annex-2 - untrusted repositories: 0 - transfers in progress: none - available local disk space: 52 gigabytes (+1 megabyte reserved) - local annex keys: 1 - local annex size: 4 bytes - known annex keys: 1 - known annex size: 4 bytes - bloom filter size: 16 mebibytes (0% full) - backend usage: - SHA256E: 2 - ~/test-annex % ls -l - total 4 - lrwxrwxrwx 1 richih richih 178 Jul 11 01:20 foo -> .git/annex/objects/91/9x/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c - ~/test-annex % git annex import ../test-annex--foo/bar - ~/test-annex % ls -l - total 4 - lrwxrwxrwx 1 richih richih 178 Jul 11 01:20 foo -> .git/annex/objects/91/9x/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c - ~/test-annex % - -"""]] diff --git a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_3_2c094bef802a2182de4fcd0def1ad29b._comment b/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_3_2c094bef802a2182de4fcd0def1ad29b._comment deleted file mode 100644 index d3870e7c9..000000000 --- a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_3_2c094bef802a2182de4fcd0def1ad29b._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 3" - date="2013-07-11T11:54:25Z" - content=""" -To expand on this a bit: - -* I meant \"ugh, me\" not \"ugh, anyone else\"; I simply did not see it... -* `git annex import` on a separate annex should copy over the symlinks and the objects behind it and then run `git annex add`, thus verifying, fixing symlinks, etc, imo. -* Something that may not be said often enough: Thanks :) -"""]] diff --git a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_4_14915c43001f7f72c9fe5119a104ef5c._comment b/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_4_14915c43001f7f72c9fe5119a104ef5c._comment deleted file mode 100644 index 4d4c1fbc5..000000000 --- a/doc/todo/wishlist:___96__git_annex_import__96___--_An_easy_way_to_get_data_into_an_annex/comment_4_14915c43001f7f72c9fe5119a104ef5c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 4" - date="2013-07-13T15:25:56Z" - content=""" -After more deliberation, there should probably be an option to not have `git annex import` run `git annex add` automagically (but still call `git annex fix`) so manual shuffling around of files is still possible. - -See [[doc/bugs/__96__git_annex_fix__96___run_on_non-annexed_files_is_no-op]] for more of the rationale on this. -"""]] diff --git a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__.mdwn b/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__.mdwn deleted file mode 100644 index df589be93..000000000 --- a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -I've seen the [[tips/using box.com as a special remote]] for using mounted WebDAV remote directory for storage of the tracked files. - -It's quite close to a scenario familiar to me, although with a difference. - -Let me describe my situation. - -I worked on a supplement to a set of textbooks. My work was dependent on the revision of the textbooks (for correct references, etc.). The textbooks were being edited by the author, and published in a WebDAV directory. - -So I set up a Git repo for my work, and also a branch to track the revisions of the textbooks which [I updated by copying them from the WebDAV directory (after mounting it)](http://unix.stackexchange.com/q/25015/4319). The branch where my work was in was either based on the textbooks branch (and rebased/merged and edited to reflect the changes in the new revisions of the textbooks when needed) or contained the repo with textbooks as a submodule. - -The textbooks were large files, so I didn't want them be a part of the Git repo with my supplement work when I publish the repo. But I wanted for those who looked into my public repo to understand how to get the textbooks I'm referring to. - -I haven't solved this problem for myself completely. Now I see I could use git-annex for this. I t would track the state of the textbooks in the repo, without actually storing them there, and whenever one would need to get the missing textbooks in a clone of the repo, git-annex could handle the download from the WebDAV directory for him, right? - -I simply wrote down the rules for reproducing these downloading and saving operations, together with source URL (as a [Makefile](https://gitorious.org/primary-school-informatics-problems/received_2011-11-mathinf-initial-edition/blobs/RULES/Makefile)): - -whenever I wanted to update the revisions of the textbooks (or to download them the first time), I would checkout the branch which included this Makefile and was for holding the textbooks, and the run: - - make get - --- this target had the temporary mountpoint for the remote directory as prerequisite, and there was a rule to create it, and mount the specified URL at it; then it would sync the files, and I could use Git to track the changes. After I was done inspecting the remote directory, I had to clean up the temporary mountpoint fby unmounting and deleting it. I didn't make it do this automatically after a `get` operation for performance reasons (caching of the remote directory would help if I wanted to access it once again). - -So, this differs from [[tips/using box.com as a special remote]] in that the tip for WebDAV suggest to handle the mounting manually, and git-annex knows nothing about the WebDAV URL where the content comes from. - -So here's my wish: a [[special remote|special remotes]] to track the WebDAV URLs in the repo, and mount the remote directory automatically under the hood, whenever one wants to get a file from there. (Then I assume it should also unmount it immediately in order to clean up after itself, despite possible inefficiencies). - -> I think the hooks are enough.. If not, you can use a hook special remote -> or the external special remote protocol to make your own custom special -> remote. So, [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_1_f46b0c9b49607e9f4f7a27f5a331ce83._comment b/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_1_f46b0c9b49607e9f4f7a27f5a331ce83._comment deleted file mode 100644 index 32dd9c039..000000000 --- a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_1_f46b0c9b49607e9f4f7a27f5a331ce83._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.153.14.141" - subject="comment 1" - date="2012-09-25T22:56:22Z" - content=""" -Note that git-annex already has the git configs `remote.<name>.annex-start-command` and `remote.<name>.annex-stop-command` which can be used to handle mounting and umounting. -"""]] diff --git a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_2_1b34e1dd72011c65e881dec2543a0373._comment b/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_2_1b34e1dd72011c65e881dec2543a0373._comment deleted file mode 100644 index 80c5ed2a9..000000000 --- a/doc/todo/wishlist:_a_spec.remote_for_network_directories_that_would_mount_them_whenever_needed___40__e.g.__44___with_WebDAV__41__/comment_2_1b34e1dd72011c65e881dec2543a0373._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://lj.rossia.org/users/imz/" - ip="79.165.56.162" - subject="comment 2" - date="2012-09-25T23:33:23Z" - content=""" -I see, thanks for pointing at these config options! Perhaps, that'll be enough. - -I'll have to see whether the information on how to access the remote copy (the source URL and how to mount it) saved in config variables will be transferred to the clones of the repo. - -AFAIU [[location tracking]], usually, git-annex would transfer the information on where to look for copies from one repo to another. -"""]] diff --git a/doc/todo/wishlist:_addurl_https:.mdwn b/doc/todo/wishlist:_addurl_https:.mdwn deleted file mode 100644 index 0a62eda6d..000000000 --- a/doc/todo/wishlist:_addurl_https:.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -It would be nice if "git annex addurl" allowed https: urls, rather than just http:. -To give an example, here is a PDF file: - - https://www.fbo.gov/utils/view?id=59ba4c8aa59101a09827ab7b9a787b05 - -If you switch the https: to http: it redirects you back to https:. - -As more sites provide https: for non-secret traffic, this becomes more of an issue. - -> I've gotten rid of the use of the HTTP library, now it just uses curl. -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_addurl_https:/comment_1_4e8f5e1fc52c3000eb2a1dad0624906e._comment b/doc/todo/wishlist:_addurl_https:/comment_1_4e8f5e1fc52c3000eb2a1dad0624906e._comment deleted file mode 100644 index fa500b1dd..000000000 --- a/doc/todo/wishlist:_addurl_https:/comment_1_4e8f5e1fc52c3000eb2a1dad0624906e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="2001:4978:f:21a::2" - subject="comment 1" - date="2013-01-26T08:44:38Z" - content=""" -This works fine with \"git annex addurl\". - -However, with --fast, it fails: - - git-annex: user error (https not supported) - -This is because the Haskell HTTP library doesn't support https yet. <https://github.com/haskell/HTTP/issues/17> Seems to be very little momentum on fixing that, perhaps I need to switch the code to use http-enumerator, which does. -"""]] diff --git a/doc/todo/wishlist:_allow_configuration_of_downloader_for_addurl.mdwn b/doc/todo/wishlist:_allow_configuration_of_downloader_for_addurl.mdwn deleted file mode 100644 index 81f7ee4c0..000000000 --- a/doc/todo/wishlist:_allow_configuration_of_downloader_for_addurl.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -It would be neat if Git annex addurl allowed a configuration option for a download manager command to do the actual download in place of wget/curl with a placeholder for the file name to save to & URL to get from (if that's all annex needs). That would allow the user to choose a graphical download manager if desired to make progress easier to monitor. The specific circumstance I'm seeing is with [[wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads]]. I found that the existing Firefox addon [FlashGot](http://flashgot.net/) can run any command with arbitrary arguments including placeholders. Right now I've got a [script](https://gist.github.com/andyg0808/5342434) that changes to a user-selected directory and then runs git-annex addurl in it with the provided url. It works fine as a download manager for FlashGot. The issue is that there is no progress information for large file downloads. If git-annex could start a separate download manager to do the actual download, then the user would be able to check status at any time, even though the git-annex command was run from a GUI and not a terminal. - -> [[done]], you can use `annex.web-download-command` now. --[[Joey]] diff --git a/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods.mdwn b/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods.mdwn deleted file mode 100644 index 849e73cc3..000000000 --- a/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -This is a wishlist item: - -Please allow the same remote to be available via different remotes. So in my LAN my remote is available using a ssh-connection, and when I travel with my laptop, the git-annex can also reach this remote using the Jabber transport. - -> [[done]]; this has always been fully supported. --[[Joey]] diff --git a/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods/comment_1_abb6263f3807160222bba1122475c89c._comment b/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods/comment_1_abb6263f3807160222bba1122475c89c._comment deleted file mode 100644 index a95ba56f9..000000000 --- a/doc/todo/wishlist:_allow_the_same_remote_to_be_accissable_via_different_methods/comment_1_abb6263f3807160222bba1122475c89c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="2001:4978:f:21a::2" - subject="comment 1" - date="2013-08-07T16:09:26Z" - content=""" -You can have as many git remotes as you like all pointing at the same repository via different paths. git-annex fully supports this AFAIK. Are you having some problem with it? -"""]] diff --git a/doc/todo/wishlist:_allow_users_to_provide_UUID_when_running___96__git_annex_init__96__.mdwn b/doc/todo/wishlist:_allow_users_to_provide_UUID_when_running___96__git_annex_init__96__.mdwn deleted file mode 100644 index 0dc9ec08a..000000000 --- a/doc/todo/wishlist:_allow_users_to_provide_UUID_when_running___96__git_annex_init__96__.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -As there's no way to permanently hide remotes and I have to recreate two repos now, I would love to be able to re-use the old UUIDs to remove clutter. - -> git-annex already provides a way to do this: Copy `.git/config` from the -> original repo (or use `git-config` to set `annex.uuid`) *before* running -> `git annex init`. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration.mdwn b/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration.mdwn deleted file mode 100644 index a1aec1d49..000000000 --- a/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -When starting the assistant when logging in to the system (`--autostart`) it choses a new port an secret everytime. Having the assistant open in a pinned firefox tab which automatically restores when firefox starts we need to get the url from `.git/annex/url` and copy/paste it into the pinned tab. It would be very nice to have a configuration option which assigns a fixed port and secret so everytime the assistant is autostarted it uses the same settings and firefox is happy to open it automatically on start. - -> Closing, I've removed the option to choose webapp ports entirely. -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration/comment_1_be53b8456eed7eadad5d4b8465c8a42b._comment b/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration/comment_1_be53b8456eed7eadad5d4b8465c8a42b._comment deleted file mode 100644 index 651937802..000000000 --- a/doc/todo/wishlist:_assistant_autostart_port_and_secret_configuration/comment_1_be53b8456eed7eadad5d4b8465c8a42b._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.64" - subject="comment 1" - date="2013-11-22T16:58:51Z" - content=""" -It's impossible to guarantee a program will be able to get a particular port. Any other program could be using that port number. - -This is why `git annex webapp` opens the webapp using whatever url the assistant has picked. I recommend that rather than using a pinned tab, you make an icon on your desktop that runs `git annex webapp`, and use that to open the app when you want it, much as you'd open any other app. If you wanted to, you could make your system run `git annex webapp` on startup instead of `git annex assistant --autostart`, and you'd get the browser tab opened automatically on start. -"""]] diff --git a/doc/todo/wishlist:_command_options_changes.mdwn b/doc/todo/wishlist:_command_options_changes.mdwn deleted file mode 100644 index b15440181..000000000 --- a/doc/todo/wishlist:_command_options_changes.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -Some suggestions for changes to command options: - - * --verbose: - * add alternate: -v - - * --from: - * replace with: -s $SOURCE || --source=$SOURCE - - * --to: - * replace with: -d $DESTINATION || --destination=$DESTINATION - - * --force: - * add alternate: -F - * "-f" was removed in v0.20110417 - * since it forces unsafe operations, should be capitalized to reduce chance of accidental usage. - -[[done]], see comments diff --git a/doc/todo/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea15f967a._comment b/doc/todo/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea15f967a._comment deleted file mode 100644 index 0ab113211..000000000 --- a/doc/todo/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea15f967a._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-04-17T23:46:37Z" - content=""" ---to and --from seem to have different semantics than --source and --destination. Subtle, but still different. - -That being said, I am not sure --from and --to are needed at all. Calling the local repo . and all remotes by their name, they are arguably redundant and removing them would make the syntax a lot prettier; mv and cp don't need them, either. - -I am not sure changing syntax at this point is considered good style though personally, I wouldn't mind adapting and would actually prefer it over using --to and --from. - --v and -q would be nice. - - -Richard -"""]] diff --git a/doc/todo/wishlist:_command_options_changes/comment_2_f6a637c78c989382e3c22d41b7fb4cc2._comment b/doc/todo/wishlist:_command_options_changes/comment_2_f6a637c78c989382e3c22d41b7fb4cc2._comment deleted file mode 100644 index 0072ae1d7..000000000 --- a/doc/todo/wishlist:_command_options_changes/comment_2_f6a637c78c989382e3c22d41b7fb4cc2._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 2" - date="2011-04-19T20:13:10Z" - content=""" -Let's see.. - -* -v is already an alias for --verbose - -* I don't find --source and --destination as easy to type or as clear as --from or --to. - -* -F is fast, so it cannot be used for --force. And I have no desire to make it easy to mistype a short option and enable --force; it can lose data. - -@richard while it would be possible to support some syntax like \"git annex copy . remote\"; what is it supposed to do if there are local files named foo and bar, and a remotes named foo and bar? Does \"git annex copy foo bar\" copy file foo to remote bar, or file bar from remote foo? I chose to use --from/--to to specify remotes independant of files to avoid such -ambiguity, which plain old `cp` doesn't have since it's operating entirely on filesystem objects, not both filesystem objects and abstract remotes. - -Seems like nothing to do here. [[done]] --[[Joey]] -"""]] diff --git a/doc/todo/wishlist:_command_options_changes/comment_3_bf1114533d2895804e531e76eb6b8095._comment b/doc/todo/wishlist:_command_options_changes/comment_3_bf1114533d2895804e531e76eb6b8095._comment deleted file mode 100644 index 9fcbae6d2..000000000 --- a/doc/todo/wishlist:_command_options_changes/comment_3_bf1114533d2895804e531e76eb6b8095._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 3" - date="2011-04-20T21:28:06Z" - content=""" -Good point. scp fixes this by using a colon, but as colons aren't needed in git-annex remotes' names... -- RichiH -"""]] diff --git a/doc/todo/wishlist:_define_remotes_that_must_have_all_files.mdwn b/doc/todo/wishlist:_define_remotes_that_must_have_all_files.mdwn deleted file mode 100644 index a3beaadae..000000000 --- a/doc/todo/wishlist:_define_remotes_that_must_have_all_files.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -I would like to be able to name a few remotes that must retain *all* annexed -files. `git-annex fsck` should warn me if any files are missing from those -remotes, even if `annex.numcopies` has been satisfied by other remotes. - -I imagine this could also be useful for bup remotes, but I haven't actually -looked at those yet. - -Based on existing output, this is what a warning message could look like: - - fsck FILE - 3 of 3 trustworthy copies of FILE exist. - FILE is, however, still missing from these required remotes: - UUID -- Backup Drive 1 - UUID -- Backup Drive 2 - Back it up with git-annex copy. - Warning - -What do you think? - -> I think that [[required_content]] will make it easy to configure -> such remotes, so this is another reason to build that. Closing -> this bug as a dup of that one; [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_1_cceccc1a1730ac688d712b81a44e31c3._comment b/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_1_cceccc1a1730ac688d712b81a44e31c3._comment deleted file mode 100644 index 1f65fd982..000000000 --- a/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_1_cceccc1a1730ac688d712b81a44e31c3._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-04-23T16:27:13Z" - content=""" -Seems to have a scalability problem, what happens when such a repository becomes full? - -Another way to accomplish I think the same thing is to pick the repositories that you would include in such a set, and make all other repositories untrusted. And set numcopies as desired. Then git-annex will never remove files from the set of non-untrusted repositories, and fsck will warn if a file is present on only an untrusted repository. -"""]] diff --git a/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_2_eec848fcf3979c03cbff2b7407c75a7a._comment b/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_2_eec848fcf3979c03cbff2b7407c75a7a._comment deleted file mode 100644 index 1855cdda0..000000000 --- a/doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_2_eec848fcf3979c03cbff2b7407c75a7a._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="gernot" - ip="87.79.209.169" - subject="comment 2" - date="2011-04-24T11:20:05Z" - content=""" -Right, I have thought about untrusting all but a few remotes to achieve -something similar before and I'm sure it would kind of work. It would be more -of an ugly workaround, however, because I would have to untrust remotes that -are, in reality, at least semi-trusted. That's why an extra option/attribute -for that kind of purpose/remote would be nice. - -Obviously I didn't see the scalability problem though. Good Point. Maybe I can -achieve the same thing by writing a log parsing script for myself? - -"""]] diff --git a/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn b/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn deleted file mode 100644 index 1b4caeff0..000000000 --- a/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -A conflict during sync or merge is something that requires user intervention, or at least notification. For that reason it would be nice if git annex returned a nonzero exit status when such a conflict happened during a sync or a merge. This is what git does after a conflicting pull, and would make it easier to spot a conflict in automated syncs without having to parse annex output or the logs. - -> Good idea, [[done]]. --[[Joey]] - -Also, it would be nice if your new `git annex status` were able to inform about remaining conflicts in the repo, for instance by reporting files with variant-XXX suffix. - -> Hmm, that would need a separate pass through the whole tree, since -> currently it can use `git ls-files` to find only modified/deleted/new -> files. I would rather not make the new `git annex status` slower for -> this. -> -> It would be possible to add it to `git annex info` (old `status`) -> which already has to look through the entire work tree. diff --git a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn b/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn deleted file mode 100644 index 837f0a587..000000000 --- a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -When addWatcher gets a permission denied, it would be helpful to display the name of the object on which the permission was denied, in the error message which shows in the webapp. - -> I have made the inotify code more robust; now it doesn't crash if it -> cannot read a directory or a file, and only logs a warning, which includes -> the directory name. -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_1_d2665e7347689b520d37561cfddf0aa8._comment b/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_1_d2665e7347689b520d37561cfddf0aa8._comment deleted file mode 100644 index de0528855..000000000 --- a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_1_d2665e7347689b520d37561cfddf0aa8._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.220" - subject="comment 1" - date="2013-09-25T18:47:13Z" - content=""" -This is an exception from the inotify library, which is what contains the `addWatch` function. I catch and display the exception. Since `addWatch` is only passed a directory to watch, the most I could do is tack on the name of the directory when displaying the exception. That does not seem likely to be much help? -"""]] diff --git a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_2_db153571a32fb072453ed583e3e9ccf4._comment b/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_2_db153571a32fb072453ed583e3e9ccf4._comment deleted file mode 100644 index e0199a42d..000000000 --- a/doc/todo/wishlist:_display_name_of_object_when_addWatcher_gets_a_permission_denied/comment_2_db153571a32fb072453ed583e3e9ccf4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl-g0hYpGY11pBP_42lHh5GWTyFuB4UwH8" - nickname="Nicolas" - subject="comment 2" - date="2013-09-25T23:08:56Z" - content=""" -Well, of course it would not be as helpful as if the inotify exception would contain the name of the exact object on which it got a permission denied (would this be a valid wishlist request for inotify?), but I think that displaying the name of the directory would already be better than nothing. -"""]] diff --git a/doc/todo/wishlist:_dropping_git-annex_history.mdwn b/doc/todo/wishlist:_dropping_git-annex_history.mdwn deleted file mode 100644 index 8286699c7..000000000 --- a/doc/todo/wishlist:_dropping_git-annex_history.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -In real life discussions with git-annex users at DebConf, the idea was proposed to have a way to drop the history of the git-annex branch, and replace it with a new branch with just the current state of the repository. - -The only thing that breaks when this is done, in theory, is `git annex log`, which can't show the location history -of files. - -The crucial thing is that this operation would only need to be done in one repository, and it would then record some information in its (new) git-annex branch, so when it was pushed to other repositories, git-annex there could notice that history had been dropped, and do the same. So, even if you have rarely used offline archive repositories, the history dropping would eventually reach them, without needing to remember to do it. - -There was speculation that it would be enough to record eg, the SHA of the top commit on the old branch. That may not be good enough, because another remote may have not gotten that SHA into its branch yet, or may have commits on top of that SHA. - -Maybe instead we want to record the SHA of the *first* commit to the old git-annex branch. This way, we can tell if the branch that got deleted is the one we're currently using. And if it is, we create a new branch with the current state of *our* branch, and then union merge the other branch into it. - -Hmm, another wrinkle is that, when this indication propigates from remote A to remote B, remote B may also have some git-annex branches available for remotes C and D, which have not transitioned, and E, which has transitioned already. It seems B should first union merge C and D into B, and then flatten B to B', and then union merge A and E into B'. - -I think that'd work! - ---[[Joey]] - -Will also allow dropping dead remotes from history. Just remove all -references to them when rewriting the branch. May or may not be desirable; -I sometimes care about dead remotes that I hope to one day recuscitate. -(OTOH, I can always run git annex fsck in them to get their location -tracking back, if I do manage to get them back.) - ---[[Joey]] - -See also : [[forum/safely_dropping_git-annex_history]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment b/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment deleted file mode 100644 index 043e674ed..000000000 --- a/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.63" - subject="comment 1" - date="2013-08-24T19:39:45Z" - content=""" -BTW, a motivation for this is that some of us have old repositories that have been upgrades all the way from annex.version 1 and have a lot of cruft in them because of it. (I have repos that have been upgraded from annex.version 0, but this would not help with that cruft which is on the master branch!) - -Also, people worry that eg, a large copy back and forth bloats history, and having a way to unbloat it if it ever gets actually annoyingly bloated would stop them pestering me. ;) -"""]] diff --git a/doc/todo/wishlist:_dropping_git-annex_history/comment_2_f6d750bfe0c9d8a2aa6bc218ca5c49cc._comment b/doc/todo/wishlist:_dropping_git-annex_history/comment_2_f6d750bfe0c9d8a2aa6bc218ca5c49cc._comment deleted file mode 100644 index a60973b82..000000000 --- a/doc/todo/wishlist:_dropping_git-annex_history/comment_2_f6d750bfe0c9d8a2aa6bc218ca5c49cc._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2013-08-27T20:02:23Z" - content=""" -If starting commit id _and_ commit id from when history is being dropped are documented, you could potentially drop more data. - -* Don't have any commits in common? Full merge. -* Only share the starting ids? Reduce local history as much as possible, and then merge. -* Share both starting id and have the last id somewhere in history? Take history from last id up to current, reduce that, and merge. - --- RichiH -"""]] diff --git a/doc/todo/wishlist:_git-annex_replicate.mdwn b/doc/todo/wishlist:_git-annex_replicate.mdwn deleted file mode 100644 index 9ac6ade75..000000000 --- a/doc/todo/wishlist:_git-annex_replicate.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -I'd like to be able to do something like the following: - - * Create encrypted git-annex remotes on a couple of semi-trusted machines - ones that have good connectivity, but non-redundant hardware - * set numcopies=3 - * run `git-annex replicate` and have git-annex run the appropriate copy commands to make sure every file is on at least 3 machines - -There would also likely be a `git annex rebalance` command which could be used if remotes were added or removed. If possible, it should copy files between servers directly, rather than proxy through a potentially slow client. - -There might be the need to have a 'replication_priority' option for each remote that configures which machines would be preferred. That way you could set your local server to a high priority to ensure that it is always 1 of the 3 machines used and files are distributed across 2 of the remaining remotes. Other than priority, other options that might help: - - * maxspace - A self imposed quota per remote machine. git-annex replicate should try to replicate files first to machines with more free space. maxspace would change the free space calculation to be `min(actual_free_space, maxspace - space_used_by_git_annex) - * bandwidth - when replication files, copies should be done between machines with the highest available bandwidth. ( I think this option could be useful for git-annex get in general) - -> `git annex sync --content` handles this now. [[done]] -> -> You do need to run it, or the assistant, on each node that needs -> to copy files to spread them through the network. -> -> A `git annex rebalance` -> is essentially the same as sshing to the remote and running `git annex -> sync --content` there. Assuming the remote repository itself has enough -> remotes set up that git-annex is able to copy files around. --[[Joey]] diff --git a/doc/todo/wishlist:_git-annex_replicate/comment_1_9926132ec6052760cdf28518a24e2358._comment b/doc/todo/wishlist:_git-annex_replicate/comment_1_9926132ec6052760cdf28518a24e2358._comment deleted file mode 100644 index cec971ee3..000000000 --- a/doc/todo/wishlist:_git-annex_replicate/comment_1_9926132ec6052760cdf28518a24e2358._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-04-22T18:27:00Z" - content=""" -While having remotes redistribute introduces some obvious security concerns, I might use it. - -As remotes support a cost factor already, you can basically implement bandwidth through that. -"""]] diff --git a/doc/todo/wishlist:_git-annex_replicate/comment_2_c43932f4194aba8fb2470b18e0817599._comment b/doc/todo/wishlist:_git-annex_replicate/comment_2_c43932f4194aba8fb2470b18e0817599._comment deleted file mode 100644 index 9d50d1531..000000000 --- a/doc/todo/wishlist:_git-annex_replicate/comment_2_c43932f4194aba8fb2470b18e0817599._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 2" - date="2011-04-23T16:22:07Z" - content=""" -Besides the cost values, annex.diskreserve was recently added. (But is not available for special remotes.) - -I have held off on adding high-level management stuff like this to git-annex, as it's hard to make it generic enough to cover use cases. - -A low-level way to accomplish this would be to have a way for `git annex get` and/or `copy` to skip files when `numcopies` is already satisfied. Then cron jobs could be used. -"""]] diff --git a/doc/todo/wishlist:_git-annex_replicate/comment_3_c13f4f9c3d5884fc6255fd04feadc2b1._comment b/doc/todo/wishlist:_git-annex_replicate/comment_3_c13f4f9c3d5884fc6255fd04feadc2b1._comment deleted file mode 100644 index e7eb06b3b..000000000 --- a/doc/todo/wishlist:_git-annex_replicate/comment_3_c13f4f9c3d5884fc6255fd04feadc2b1._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" - nickname="Justin" - subject="comment 3" - date="2011-04-23T17:54:42Z" - content=""" -Hmm, so it seems there is almost a way to do this already. - -I think the one thing that isn't currently possible is to have 'plain' ssh remotes.. basically something just like the directory remote, but able to take a ssh user@host/path url. something like sshfs could be used to fake this, but for things like fsck you would want to do the sha1 calculations on the remote host. -"""]] diff --git a/doc/todo/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a9948c9._comment b/doc/todo/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a9948c9._comment deleted file mode 100644 index 3805464a6..000000000 --- a/doc/todo/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a9948c9._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 4" - date="2011-09-19T18:54:46Z" - content=""" -git annex get/copy/drop all now support a --auto flag, which makes them only act on files that have not enough or too many copies. This allows for some crude replication; it doesn't take into account which repositories should be filled up more (beyond honoring annex.diskreserve), nor does it try to optimally use bandwidth (beyond honoring configured annex-cost). You have to run it in every repository that you want to participate in the replication, too. But it's probably a Good Enough solution. See [[walkthrough/automatically_managing_content]]. -"""]] diff --git a/doc/todo/wishlist:_git_annex_group_remote_return_the_group.mdwn b/doc/todo/wishlist:_git_annex_group_remote_return_the_group.mdwn deleted file mode 100644 index 5c8d8b011..000000000 --- a/doc/todo/wishlist:_git_annex_group_remote_return_the_group.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -Hi, - -It would be good if the command - - git annex group repository - -returned the current list of groups the repository belongs to...(can it belong to more than one?) - -Currently the command requires an additional parameter to set the group. - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults.mdwn b/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults.mdwn deleted file mode 100644 index e1dc89a96..000000000 --- a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -I am running centralized git-annex exclusively. - -Similar to - - git annex get - -I'd like to have a - - git annex put - -which would put all files on the default remote(s). - -My main reason for not wanting to use copy --to is that I need to specify the remote's name in this case which makes writing a wrapper unnecessarily hard. Also, this would allow - - mr push - -to do the right thing all by itself. - -> I feel that the new `git annex sync --content` is pretty close to what's -> requested here. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_1_d5413c8acce308505e4e2bec82fb1261._comment b/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_1_d5413c8acce308505e4e2bec82fb1261._comment deleted file mode 100644 index fe1d5520f..000000000 --- a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_1_d5413c8acce308505e4e2bec82fb1261._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-04-04T18:13:46Z" - content=""" -This begs the question: What is the default remote? It's probably *not* the same repository that git's master branch is tracking (ie, origin/master). It seems there would have to be an annex.defaultremote setting. - -BTW, mr can easily be configured on a per-repo basis so that \"mr push\" copies to somewhere: `push = git push; git annex push wherever` -"""]] diff --git a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_2_0aa227c85d34dfff4e94febca44abea8._comment b/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_2_0aa227c85d34dfff4e94febca44abea8._comment deleted file mode 100644 index 3090b575b..000000000 --- a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_2_0aa227c85d34dfff4e94febca44abea8._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2011-04-04T20:45:30Z" - content=""" -In my case, the remotes are the same, but adding a new option could make sense. - -And while I can tell mr what to do explicitly, I would prefer if it did the right thing all by itself. Having to change configs in two separate places is less than ideal. - -I am not sure what you mean by `git annex push` as that does not exist. Did you mean copy? -"""]] diff --git a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment b/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment deleted file mode 100644 index 01dc7813f..000000000 --- a/doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 1" - date="2011-04-04T10:28:01Z" - content=""" -Going one step further, a --min-copy could put all files so that numcopies is satisfied. --all could push to all available ones. - -To take everything another step further, if it was possible to group remotes, one could act on the groups. \"all\" would be an obvious choice for a group that always exists, everything else would be set up by the user. -"""]] diff --git a/doc/todo/wishlist:_git_annex_status.mdwn b/doc/todo/wishlist:_git_annex_status.mdwn deleted file mode 100644 index 6bb5d71f1..000000000 --- a/doc/todo/wishlist:_git_annex_status.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -Ideally, it would look similar to this. And yes, I put "put" in there ;) - - non-annex % git annex status - git annex status: error: not a git annex repository - annex % git annex status - annex object storage version: A - annex backend engine: {WORM,SHA512,...} - Estimated local annex size: B MiB - Estimated total annex size: C MiB - Files without file size information in local annex: D - Files without file size information in total annex: E - Last fsck: datetime - Last git pull: datetime - $annex_name - Last git push: datetime - $annex_name - Last git annex get: datetime - $annex_name - Last git annex put: datetime - $annex_name - annex % - -Datetime could be ISO's YYYY-MM-DDThh:mm:ss or, personal preference, YYYY-MM-DD--hh-mm-ss. I prefer the latter as it's DNS-, tag- and filename-safe which is why I am using it for everything. In a perfect world, ISO would standardize YYYY-MM-DD-T-hh-mm-ss-Z[-SSSSSSSS][--$timezone], but meh. - -[[done]] diff --git a/doc/todo/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090._comment b/doc/todo/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090._comment deleted file mode 100644 index 7b5e7bd44..000000000 --- a/doc/todo/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 1" - date="2011-04-08T07:23:08Z" - content=""" -+1 for this feature, I've been longing for something like this other than rolling my own perl/shell scripts to parse the outputs of \"git annex whereis .\" to see how many files are on my machine or not. -"""]] diff --git a/doc/todo/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824._comment b/doc/todo/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824._comment deleted file mode 100644 index 21f9d713c..000000000 --- a/doc/todo/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="http://christian.amsuess.com/chrysn" - nickname="chrysn" - subject="format, respect working directory" - date="2011-04-26T12:31:02Z" - content=""" -we could include the information about the current directory as well, if the command is not issued in the local git root directory. to avoid large numbers of similar lines, that could look like this: - - Estimated annex size: B MiB (of C MiB; [B/C]%) - Estimated annex size in $PWD: B' MiB (of C' MiB; [B'/C']%) - -with the percentages being replaced with \"complete\" if really all files are present (and not just many enough for the value to be rounded to 100%). -"""]] diff --git a/doc/todo/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7._comment b/doc/todo/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7._comment deleted file mode 100644 index 39986144b..000000000 --- a/doc/todo/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 3" - date="2011-05-17T01:15:10Z" - content=""" -What a good idea! - -150 lines of haskell later, I have this: - -<pre> -# git annex status -supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL -supported remote types: git S3 bup directory rsync hook -local annex keys: 32 -local annex size: 58 megabytes -total annex keys: 38158 -total annex size: 6 terabytes (but 1632 keys have unknown size) -backend usage: - SHA1: 1789 - WORM: 36369 -</pre> -"""]] diff --git a/doc/todo/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94._comment b/doc/todo/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94._comment deleted file mode 100644 index f006f88a0..000000000 --- a/doc/todo/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://christian.amsuess.com/chrysn" - nickname="chrysn" - subject="status of other remotes?" - date="2011-06-15T08:39:24Z" - content=""" -using the location tracking information, it should be possible to show the status of other remotes as well. what about supporting `--from=...` or `--all`? (thus, among other things, one could determine if a remote has a complete checkout.) -"""]] diff --git a/doc/todo/wishlist:_git_backend_for_git-annex.mdwn b/doc/todo/wishlist:_git_backend_for_git-annex.mdwn deleted file mode 100644 index fd1b40bff..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Preamble: Obviously, the core feature of git-annex is the ability to keep a subset of files in a local repo. The main trade-off is that you don't get version tracking. - -Use case: On my laptop, I might not have enough disk space to store everything. Not so for my main box nor my backup server. And I would _really_ like to have proper version tracking for many of my files. Thus... - -Wish: ...why not use git as a version backend? That way, I could just push all my stuff to the central instance(s) and have the best of both worlds. Depending on what backend is used in the local repos, it might make sense to define a list of supported client backends with pre-computed keys. - --- RichiH - -[[done]] (bup) diff --git a/doc/todo/wishlist:_git_backend_for_git-annex/comment_1_04319051fedc583e6c326bb21fcce5a5._comment b/doc/todo/wishlist:_git_backend_for_git-annex/comment_1_04319051fedc583e6c326bb21fcce5a5._comment deleted file mode 100644 index a691393b1..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex/comment_1_04319051fedc583e6c326bb21fcce5a5._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-03-28T16:01:30Z" - content=""" -Indeed, see [[todo/add_a_git_backend]], where you and I have already discussed this idea. :) - -With the new support for special remotes, which will be used by S3, it would be possible to make such a git repo, using bup, be a special remote. I think it would be pretty easy to implement now. Not a priority for me though. -"""]] diff --git a/doc/todo/wishlist:_git_backend_for_git-annex/comment_2_7f529f19a47e10b571f65ab382e97fd5._comment b/doc/todo/wishlist:_git_backend_for_git-annex/comment_2_7f529f19a47e10b571f65ab382e97fd5._comment deleted file mode 100644 index 14798e7a7..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex/comment_2_7f529f19a47e10b571f65ab382e97fd5._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2011-03-28T17:47:38Z" - content=""" -On the plus side, the past me wanted exactly what I had in mind. - -On the meh side, I really forgot about this conversation :/ - -When you say this todo is not a priority, does that mean there's no ETA at all and that it will most likely sleep for a long time? Or the almost usual \"what the heck, I will just wizard it up in two lines of haskell\"? - --- RichiH -"""]] diff --git a/doc/todo/wishlist:_git_backend_for_git-annex/comment_3_a077bbad3e4b07cce019eb55a45330e7._comment b/doc/todo/wishlist:_git_backend_for_git-annex/comment_3_a077bbad3e4b07cce019eb55a45330e7._comment deleted file mode 100644 index 8c3286d27..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex/comment_3_a077bbad3e4b07cce019eb55a45330e7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 3" - date="2011-03-28T20:05:13Z" - content=""" -Probably more like 150 lines of haskell. Maybe just 50 lines if the bup repository is required to be on the same computer as the git-annex repository. - -Since I do have some repositories where I'd appreciate this level of assurance that data not be lost, it's mostly a matter of me finding a free day. -"""]] diff --git a/doc/todo/wishlist:_git_backend_for_git-annex/comment_4_ecca429e12d734b509c671166a676c9d._comment b/doc/todo/wishlist:_git_backend_for_git-annex/comment_4_ecca429e12d734b509c671166a676c9d._comment deleted file mode 100644 index cf649a8a2..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex/comment_4_ecca429e12d734b509c671166a676c9d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 4" - date="2011-03-28T20:45:35Z" - content=""" -Personally, I would not mind a requirement to keep a local bup repo. I wouldn't want my data to to unncessarily complex setups, anyway. -- RichiH -"""]] diff --git a/doc/todo/wishlist:_git_backend_for_git-annex/comment_5_3459f0b41d818c23c8fb33edb89df634._comment b/doc/todo/wishlist:_git_backend_for_git-annex/comment_5_3459f0b41d818c23c8fb33edb89df634._comment deleted file mode 100644 index a1300f2e6..000000000 --- a/doc/todo/wishlist:_git_backend_for_git-annex/comment_5_3459f0b41d818c23c8fb33edb89df634._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 5" - date="2011-04-08T20:59:37Z" - content=""" -My estimates were pretty close -- the new bup special remote type took 133 lines of code, and 2 hours to write. A testament to the flexibility of the special remote infrastructure. :) -"""]] diff --git a/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__.mdwn b/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__.mdwn deleted file mode 100644 index 420fb882c..000000000 --- a/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -I recently tried to use unannex for a large repo and it failed because the repo size was more than half the disk size. Unannex should work incrementally so this isn't a problem. - -Proposed solution: -copy a file, hash it, iff hash check is okay, delete from objects, continue to next file - -> That won't work, because multiple files can point to a key. -> -> I am not happy with unannex's behavior, but I was less happy -> when people were constantly filing bugs about it misbehaving in that -> situttion. If you dislike the copying, use --fast. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__/comment_1_067b29fc47d26b9da0766f9810684ae8._comment b/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__/comment_1_067b29fc47d26b9da0766f9810684ae8._comment deleted file mode 100644 index 372bb621f..000000000 --- a/doc/todo/wishlist:_incremental_unannex___40__currently_requires_twice_the_size_of_repo_to_complete__41__/comment_1_067b29fc47d26b9da0766f9810684ae8._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="GLITTAH" - ip="78.108.63.46" - subject="comment 1" - date="2013-11-19T18:15:15Z" - content=""" -Perhaps when unannex is invoked, it could check to see if there is enough disk space before it begins copying files. Maybe even warn the user of too little disk space and remind them of --fast. - -(Sorry for the dupe!) -"""]] diff --git a/doc/todo/wishlist:_metadata_metadata_view.mdwn b/doc/todo/wishlist:_metadata_metadata_view.mdwn deleted file mode 100644 index a4b243cdd..000000000 --- a/doc/todo/wishlist:_metadata_metadata_view.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -Currently looking at the metadata and views. - -One of the things I would like to do is have a view that shows files by metadata metadata.. for example, "when the file last had tags changed". - -Something along the lines of - - $ git annex view metadata-tag-mtime=YYYYMMDD - view (searching...) - - Switched to branch 'views/metadata/tag/mtime/YYYYMMDD' - ok - - $ ls - 20130816 - 20130921 - 20131015 - -This would allow me to review files that haven't had any tag changes applied for a while and thus, may need the tags updating. - -I've done this in every tagging system I've used by (ab)using mtime, but that requires an additional step (of touching the file). - -> [[done]]; "$field-lastchanged" is automatically made available for each -> field! --[[Joey]] diff --git a/doc/todo/wishlist:_metadata_metadata_view/comment_1_79dbf48cf2e0d649f32bd077f0c9bc5a._comment b/doc/todo/wishlist:_metadata_metadata_view/comment_1_79dbf48cf2e0d649f32bd077f0c9bc5a._comment deleted file mode 100644 index 126a9148c..000000000 --- a/doc/todo/wishlist:_metadata_metadata_view/comment_1_79dbf48cf2e0d649f32bd077f0c9bc5a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 1" - date="2014-03-18T17:09:55Z" - content=""" -I think this would be pretty easy to do actually. No need to trawl through git history to find when a field changed; the metadata log file format includes the timestamp when a line was changed, so it would only need to find the newest timestamp for the field in the current version of the file. -"""]] diff --git a/doc/todo/wishlist:_metadata_metadata_view/comment_2_5763d0e403c476ac692c1cd50630f824._comment b/doc/todo/wishlist:_metadata_metadata_view/comment_2_5763d0e403c476ac692c1cd50630f824._comment deleted file mode 100644 index 8b3fc3108..000000000 --- a/doc/todo/wishlist:_metadata_metadata_view/comment_2_5763d0e403c476ac692c1cd50630f824._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="Xyem" - ip="87.194.19.134" - subject="comment 2" - date="2014-03-19T11:18:19Z" - content=""" -Can $field be a glob? i.e. * - -I'm looking for the files to be organised to the last change date to *any* metadata, not a specific field. - -For example, I may have added some vacation photos and set some metadata (location=Malta), a couple of months later, gone through and added metadata to some of them (person=Susan, event=Wedding Reception). 3 months later, I want to see a directory containing those that were initially added and metadata'd(?) with \"location=Malta\" and not touched since, and another showing those that had gotten additional metadata so I know which ones I should be looking at. -"""]] diff --git a/doc/todo/wishlist:_metadata_metadata_view/comment_3_797e6578c60d8e2ed1f61a8d6403575f._comment b/doc/todo/wishlist:_metadata_metadata_view/comment_3_797e6578c60d8e2ed1f61a8d6403575f._comment deleted file mode 100644 index aff5afbcf..000000000 --- a/doc/todo/wishlist:_metadata_metadata_view/comment_3_797e6578c60d8e2ed1f61a8d6403575f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.102" - subject="comment 3" - date="2014-03-19T23:14:24Z" - content=""" -I added a toplevel \"lastchanged\" that applies to all the fields. (Also when the last change was unsetting a field, the toplevel lastchanged will show the time of that which is otherwise not visible by collecting the lastchanged-* fields). -"""]] diff --git a/doc/todo/wishlist:_metadata_metadata_view/comment_4_d271fe711b3fe5ffeb52f1caf44622b3._comment b/doc/todo/wishlist:_metadata_metadata_view/comment_4_d271fe711b3fe5ffeb52f1caf44622b3._comment deleted file mode 100644 index 4bc147c4e..000000000 --- a/doc/todo/wishlist:_metadata_metadata_view/comment_4_d271fe711b3fe5ffeb52f1caf44622b3._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="Xyem" - ip="87.194.19.134" - subject="comment 4" - date="2014-03-20T08:14:20Z" - content=""" -Awesome! :) - -Thank you for adding this, I hope others find it as useful as I will. -"""]] diff --git a/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn b/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn deleted file mode 100644 index 8b6350a55..000000000 --- a/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -as of git-annex version 3.20110719, all git-annex commits only contain the word "update" as a commit message. given that the contents of the commit are pretty non-descriptive (SHA1 hashes for file names, uuids for repository names), i suggest to have more descriptive commit messages, as shown here: - - /mnt/usb_disk/photos/2011$ git annex get - /mnt/usb_disk/photos/2011$ git show git-annex - [...] - usb-disk-photos: get 2011 - - * 10 files retrieved from 2 sources (9 from local-harddisk, 1 from my-server) - * 120 files were already present - * 2 files could not be retrieved - /mnt/usb_disk/photos/2011$ cd ~/photos/2011/07 - ~/photos/2011/07$ git copy --to my-server - ~/photos/2011/07$ git show git-annex - [...] - local-harddisk: copy 2011/07 to my-server - - * 20 files pushed - ~/photos/2011/07$ - -in my opinion, the messages should at least contain - -* what command was used -* in which repository they were executed -* which files or directories they affected (not necessarily all files, but what was given on command line or implicitly from the working directory) - ---[[chrysn]] - -> The implementation of the git-annex branch precludes more descriptive -> commit messages, since a single commit can include changes that were -> previously staged to the branch's index file, or spooled to its journal -> by other git-annex commands (either concurrently running or -> interrupted commands, or even changes needed to automatically merge -> other git-annex branches). -> -> It would be possible to make it *less* verbose, with an empty commit -> message. :) --[[Joey]] - ->> Closing as this is literally impossible to do without making ->> git-annex worse. [[done]] --[[Joey]] - -> I'm not sure that the requested feature is that far off. There are two -> aspects, that can be solved relatively easy: -> -> * Recording the name of the remote the commit was issued on. This -> information is simply constant per remote. -> -> * While it is true that there is no 1 on 1 correspondence between commands -> and git-annex commits, it would be entirely possible to add a "message -> journal". Every command issued would start out with writing its -> invocation to the message journal. At the time the journal ends up being -> committed to the git-annex branch, the message journal is used as the -> body of the commit message and truncated. -> -> It is true that these suggestions do not address every aspect of the -> original report, but they would solve about 90%. --[[HelmutGrohne]] diff --git a/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl.mdwn b/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl.mdwn deleted file mode 100644 index d0b847933..000000000 --- a/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -I'm testing out an idea of using filter-branch on a git repository to both retroactively annex and AND record a weburl for all relevant files. - -c.f. [http://git-annex.branchable.com/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/](http://git-annex.branchable.com/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/) - -The bottleneck I'm hitting here seems to be the fact that `git annex addurl` diligently checks each url to see that it is accessible, which adds up quickly if many files are to be processed. - -It would be great if addurl had an option to disable checking the url, in order to speed up large batch jobs like this. - -> --relaxed added [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl/comment_1_868a380faa1e55faa3c2d314e3258e86._comment b/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl/comment_1_868a380faa1e55faa3c2d314e3258e86._comment deleted file mode 100644 index 4bdf4c97b..000000000 --- a/doc/todo/wishlist:_option_to_disable_url_checking_with_addurl/comment_1_868a380faa1e55faa3c2d314e3258e86._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 1" - date="2013-03-11T18:19:34Z" - content=""" -It does this to get the size of the url, so it can record this in the key. It would be possible to add a flag to skip that (--fast is already taken of course), but then you tend to get a lot of keys in your repository with no size info attached, which makes `git annex status` complain that it cannot tell you exactly how big your repo is, and is generally not the best. It also defeats annex.diskreserve checking, for example. - -With --fast, the size is the only info available to ensure that the content behind the url has not changed when downloading it later. I suppose for some urls you may not want that checked, and so a --relaxed type option could make sense in that use case as well, although with the above caveat. -"""]] diff --git a/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one.mdwn b/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one.mdwn deleted file mode 100644 index f9b4c8c35..000000000 --- a/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -I just added a CIA bot to #vcs-home and tracking commits immediately would be nice. -- RichiH - -[[done]] diff --git a/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one/comment_1_3480b0ec629ef29a151408d869186bf8._comment b/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one/comment_1_3480b0ec629ef29a151408d869186bf8._comment deleted file mode 100644 index 5d0edce2e..000000000 --- a/doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one/comment_1_3480b0ec629ef29a151408d869186bf8._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-09-19T18:57:52Z" - content=""" -JFTR, pushing now happens automatically from branchable. -"""]] diff --git a/doc/todo/wishlist:_query_things_like_description__44___trust_level.mdwn b/doc/todo/wishlist:_query_things_like_description__44___trust_level.mdwn deleted file mode 100644 index d158850cd..000000000 --- a/doc/todo/wishlist:_query_things_like_description__44___trust_level.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -It would be helpful to have a way to query things like a repository's description and trust level, without having to poke in the git-annex branch. For example, "git annex describe ." currently clears the description but could print the current one instead. - -> `git annex status` now breaks down the repository list by type. [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_1_14311384788312b96e550749ab7de9ea._comment b/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_1_14311384788312b96e550749ab7de9ea._comment deleted file mode 100644 index 3ac4ba267..000000000 --- a/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_1_14311384788312b96e550749ab7de9ea._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-10-27T17:09:33Z" - content=""" -`git annex describe` only sets the description to avoid complication. Imagine using it in a script for example. - -`git annex status` shows the description. It does not show the trust level because I have not thought of a visually pleasing and compact way to show it in the repository list there.. suggestions appreciated, since the same list is used by `whereis`, and showing trust levels there would be particularly useful. -"""]] diff --git a/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_2_342d1ac07573c7ef4e27f003a692e261._comment b/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_2_342d1ac07573c7ef4e27f003a692e261._comment deleted file mode 100644 index 3bb92919f..000000000 --- a/doc/todo/wishlist:_query_things_like_description__44___trust_level/comment_2_342d1ac07573c7ef4e27f003a692e261._comment +++ /dev/null @@ -1,32 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2011-10-29T18:28:13Z" - content=""" -Possible solutions: - -This: - - trusted repositories: - UUID -- foo - semi-trusted repositories: - UUID -- bar - untrusted repositories: - UUID -- baz - -or this: - - UUID -- trusted -- foo - UUID -- semi-trusted -- bar - UUID -- untrusted -- baz - -or this: - - known repositories (!/*/X): - UUID -- ! foo - UUID -- * bar - UUID -- X baz - -If you want to reformat this output, putting 'here', 'origin', etc into fixed formatting might make sense, as well. -- Richard -"""]] diff --git a/doc/todo/wishlist:_simple_url_for_webapp.mdwn b/doc/todo/wishlist:_simple_url_for_webapp.mdwn deleted file mode 100644 index 4549f2e74..000000000 --- a/doc/todo/wishlist:_simple_url_for_webapp.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -### Please describe the problem. - -The environment is os/x with chrome as the browser. - -Let's say I close the tab with the webapp running in it. The 'git-annex webapp' process is still running, according to 'ps'. - -So I open a new tab, but then what do I type into the browser url bar to get the app back? What is usually there is a loopback address and an authorisation hash. - -* Should I double-click on the git-annex icon in the dock (or Applications directory)? -* I figured out from observing the startup that if I give the url ://localhost/Users/me/annex/.git/annex/webapp.html I will get redirected to the right place. -Should I set up a bookmark for that? - -### What steps will reproduce the problem? - -see above. - -### What version of git-annex are you using? On what operating system? - -Version: 4.20130723-ge023649 -Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS -os: os/x 10.8.4 - -### Please provide any additional information below. - -I notice that in the webapp ui, all the items at the top of the page highlight when one hovers over them and have useful URLs attached, -with the exception of the 'git-annex' item at the far left.What if that had the entry point url attached to it (so one could bookmark that)? - -> The git-annex assistant is designed to stay running in the background whether you have the web browser open or not. You can open the web display at any time by -> using the git-annex menu item (on linux) or running the git-annex-webapp -> program (which is in the DMG on OSX). -> -> If the file:// url were exposed to users, it would not work if -> the assistant had not already been started. This is why there is a program -> to open the webapp, not an url. -> -> Not a bug; [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_simple_url_for_webapp/comment_1_552aad504fbb68d1f85abfde8c535e69._comment b/doc/todo/wishlist:_simple_url_for_webapp/comment_1_552aad504fbb68d1f85abfde8c535e69._comment deleted file mode 100644 index 1211be9b5..000000000 --- a/doc/todo/wishlist:_simple_url_for_webapp/comment_1_552aad504fbb68d1f85abfde8c535e69._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkfHTPsiAcHEEN7Xl7WxiZmYq-vX7azxFY" - nickname="Vincent" - subject="comment 1" - date="2013-07-24T14:46:22Z" - content=""" -typo - -url should be - file://localhost/Users/me/annex/.git/annex/webapp.html -"""]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage.mdwn b/doc/todo/wishlist:_simpler_gpg_usage.mdwn deleted file mode 100644 index 1236ee234..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -This is my current understanding on how one must use gpg with git-annex: - - * Generate(or copy around) a gpg key on every machine that needs to access the encrypted remote. - * git annex initremote myremote encryption=KEY for each key that you generated - -What I'm trying to figure out is if I can generate a no-passphrase gpg key and commit it to the repository, and have git-annex use that. That way any new clones of the annex automatically have access to any encrypted remotes, without having to do any key management. - -I think I can generate a no-passphrase key, but then I still have to manually copy it around to each machine. - -I'm not a huge gpg user so part of this is me wanting to avoid having to manage and keeping track of the keys. This would probably be a non-issue if I used gpg on more machines and was more comfortable with it. - -[[done]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c5._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c5._comment deleted file mode 100644 index f96f5c377..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c5._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" - nickname="Justin" - subject="comment 1" - date="2012-04-29T01:41:57Z" - content=""" -Thinking about this more, I think minimally git-annex could support a - - remote.<name>.gpg-options - -or - - remote.<name>.gpg-keyring - -for options to be passed to gpg. I'm not sure how automatically setting it to $ANNEX_ROOT/.gnupg/.. would work. - - -I need to read the encryption code to fully understand it, but I also wonder if there is not also a way to just bypass gpg entirely and store the remote-encryption keys locally in plain text. -"""]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment deleted file mode 100644 index 2e12d86d4..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 2" - date="2012-04-29T02:39:20Z" - content=""" -The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certainly be possible to store the symmetric cipher unencrypted in the git repo. - -I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up. -"""]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dabd._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dabd._comment deleted file mode 100644 index 051f17a24..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dabd._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 3" - date="2012-04-29T02:41:38Z" - content=""" -BTW re your Tweet.. I was so happy to be able to use 'c i a' in Crypto.hs. :) -"""]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661ef._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661ef._comment deleted file mode 100644 index c9e337541..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661ef._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" - nickname="Justin" - subject="comment 4" - date="2012-04-29T03:09:03Z" - content=""" -I got a good laugh out of it :-) - -Storing the key unencrypted would make things easier.. I think at least for my use-cases I don't require another layer of protection on top of the ssh keys that provide access to the encrypted remotes themselves. -"""]] diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068ca._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068ca._comment deleted file mode 100644 index 60b98bde5..000000000 --- a/doc/todo/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068ca._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 5" - date="2012-04-29T18:04:13Z" - content=""" -encryption=shared is now supported -"""]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote.mdwn b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote.mdwn deleted file mode 100644 index 229dc258b..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -The [[Web special remote|special remotes/web]] could possibly be improved by detecting when URLs reference a Youtube video page and using [youtube-dl](http://rg3.github.com/youtube-dl/) instead of wget to download the page. Youtube-dl can also handle several other video sites such as vimeo.com and blip.tv, so if this idea were to be implemented, it might make sense to borrow the regular expressions that youtube-dl uses to identify video URLs. A quick grep through the youtube-dl source for the identifier _VALID_URL should find those regexes (in Python's regex format). - -> This is something I've thought about doing for a while.. -> Two things I have not figured out: -> -> * Seems that this should really be user-configurable or a plugin system, -> to handle more than just this one case. -> * Youtube-dl breaks from time to time, I really trust these urls a lot -> less than regular urls. Perhaps per-url trust levels are called for by -> this. -> -> --[[Joey]] - -> > There's a library for this called [quvi](http://quvi.sourceforge.net/) which supports many -> > different sites and also allows fetching the URL (as opposed to just -> > downloading the file). It seems to me this would be the best tool -> > for this task. One problem to consider here is that a single youtube -> > URL may yield different file contents depending on the quality -> > chosen. Also, it seems that the URLs guessed by quvi may be -> > ephemeral. --[[anarcat]] - -> [[done]]!!! --[[Joey]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_1_1a383c30df4fb1767f13d8c670b0c0b5._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_1_1a383c30df4fb1767f13d8c670b0c0b5._comment deleted file mode 100644 index 5569ff94a..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_1_1a383c30df4fb1767f13d8c670b0c0b5._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://rmunn.myopenid.com/" - nickname="rmunn" - subject="comment 1" - date="2012-06-12T15:52:35Z" - content=""" -* One way to handle the configuration might be with regular expressions. If the URL matches regex A, handle it with downloader A' (with option set A''). If the URL matches regex B, handle it with downloader B' and option set B''. And so on. Then if nothing is matched, the default downloader is wget/curl. - -* In my experience, youtube-dl breakages are fixed relatively quickly; a much more serious problem from a trust standpoint is that Youtube videos often disappear. Sometimes due to a legitimate copyright claim, sometimes due to illegitimate copyright claims. (I've seen both happen). Or because the video uploader decided to upload *other* videos that violated copyright, and Youtube closed his/her account, thereby removing *all* his/her videos from the Web. Youtube is definitely an untrustworthy repository as far as \"the file will still be there later on\" is concerned. Perhaps a default trust relationship could go along with the regexes? URLs matching regex A are semitrusted, while URLs matching regex B are untrusted. -"""]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment deleted file mode 100644 index a25b3c89d..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.63" - subject="quvi thoughts. excited!" - date="2013-08-22T18:22:51Z" - content=""" -Anarcat's quvi suggestion is interesting, because it seems to simplify the whole thing down to just `addurl`, which git-annex is already good at. - -If quvi manages to find the url that can be used to download the actual video file, without needing to run a special downloader, then all you really need, it seems, is `git annex addurl --relaxed $(quvi youtube-url)` The --relaxed will make git-annex not care if the content or size of the url's content varies in the future. Since --relaxed skips the actual download, you'd want to follow that with `git annex get`, since we don't know how long these urls will last.. - -I suppose git-annex could, if quvi is available, make any attempt to download a web special remote url that -matches the `quvi --support` output run the url through quvi to get the real url and download that instead. The difficulties with this approach: - -* would need to read and parse `quvi --support` every time it gets an url from the web special remote? (I don't think I'd want to link with libquvi, although that would be possible, just because this is an edge thing.) -* what it an url that had been supported stopped being supported -- we'd not want to download the raw url in that case -* putting the quvi support here doesn't allow relaxed mode to be set when `addurl` adds the url. - -Maybe it would be better to keep the support in `addurl`, and record the url generated by quvi. That url would probably be more likely to break in the future, but that kind of breakage is why `git annex untrust web` is wise.. -Keeping the support in `addurl` would also let it use the title that quvi also returns to determine the filename it creates. -"""]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment deleted file mode 100644 index c4d8cf754..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.63" - subject="comment 3" - date="2013-08-22T18:44:15Z" - content=""" -Since the quvi urls are quite likely to break as the CDNs etc change things around, maybe it would be better to somehow have addurl tag an url as needing to be downloaded with quvi. Then `git annex get` could re-run quvi to get an url to download. - -We could expand url syntax for this. `quvi:http://youtube.com/foo` -This also allows for future expansion for other similar things. - -I'd be inclined to still make `addurl` automatically try quvi to see if an url is supported, rather than requiring the user fix up the url themselves. But if trying quvi turns out to be too expensive, manually specifying it in the url would also work. -"""]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_4_a57947ed257b28bbe995a68bfeb5eeaa._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_4_a57947ed257b28bbe995a68bfeb5eeaa._comment deleted file mode 100644 index ee0ab45e7..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_4_a57947ed257b28bbe995a68bfeb5eeaa._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://rmunn.myopenid.com/" - nickname="rmunn" - subject="comment 4" - date="2013-08-24T15:31:36Z" - content=""" -Either quvi or youtube-dl might be a good possibility: youtube-dl has the --get-url option (or -g for short) that outputs just the download URL (and nothing else) to stdout. So if for some reason quvi turned out not to be suitable, it wouldn't necessarily mean the idea would have to be abandoned. -"""]] diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_5_a0612ae05dbda7f7935be648b42b30fc._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_5_a0612ae05dbda7f7935be648b42b30fc._comment deleted file mode 100644 index 38ac09511..000000000 --- a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_5_a0612ae05dbda7f7935be648b42b30fc._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://id.koumbit.net/anarcat" - ip="72.0.72.144" - subject="aaaaawesome!" - date="2013-08-26T04:43:27Z" - content=""" -wow, thanks! i am happy my little suggestion led to an actual implentation, great! -"""]] diff --git a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync.mdwn b/doc/todo/wishlist:_special_remote_for_sftp_or_rsync.mdwn deleted file mode 100644 index d3c855655..000000000 --- a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -i think it would be useful to have a fourth kind of [[special_remotes]] -that connects to a dumb storage using sftp or rsync. this can be emulated -by using sshfs, but that means lots of round-trips through the system and -is limited to platforms where sshfs is available. - -typical use cases are backups to storate shared between a group of people -where each user only has limited access (sftp or rsync), when using -[[special_remotes/bup]] is not an option. - -an alternative to implementing yet another special remote would be to have -some kind of plugin system by which external programs can provide an -interface to key-value stores (i'd implement the sftp backend myself, but -haven't learned haskell yet). - -> Ask and ye [[shall receive|special_remotes/rsync]]. -> -> Sometimes I almost think that a generic configurable special remote that -> just uses configured shell commands would be useful.. But there's really -> no comparison with sitting down and writing code tuned to work with -> a given transport like rsync, when it comes to reliability and taking -> advantage of its abilities (like resuming). --[[Joey]] - ->> big thanks, and bonus points for identical formats, so converting from ->> directory to rsync is just a matter of changing ``type`` from ``directory`` ->> to ``rsync`` in ``.git-annex/remote.log`` and replacing the directory info ->> with ``annex-rsyncurl = <host>:<dir>`` in ``.git/config``. --[[chrysn]] - -[[done]] diff --git a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_1_6f07d9cc92cf8b4927b3a7d1820c9140._comment b/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_1_6f07d9cc92cf8b4927b3a7d1820c9140._comment deleted file mode 100644 index c513ed400..000000000 --- a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_1_6f07d9cc92cf8b4927b3a7d1820c9140._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 1" - date="2011-04-28T07:47:38Z" - content=""" -+1 for a generic user configurable backend that a user can put shell commands in, which has a disclaimer such that if a user hangs themselves with misconfiguration then its their own fault :P - -I would love to be able to quickly plugin an irods/sector set of put/get/delete/stat(get info) commands into git-annex to access my private clouds which aren't s3 compatible. -"""]] diff --git a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_2_84e4414c88ae91c048564a2cdc2d3250._comment b/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_2_84e4414c88ae91c048564a2cdc2d3250._comment deleted file mode 100644 index 6243708f9..000000000 --- a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_2_84e4414c88ae91c048564a2cdc2d3250._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 2" - date="2011-04-28T21:22:03Z" - content=""" -Ask and ye shalle receive with an Abbot on top: [[special_remotes/hook]] -"""]] diff --git a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_3_79de7ac44e3c0f0f5691a56d3fb88897._comment b/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_3_79de7ac44e3c0f0f5691a56d3fb88897._comment deleted file mode 100644 index dc21ec488..000000000 --- a/doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_3_79de7ac44e3c0f0f5691a56d3fb88897._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 3" - date="2011-04-29T10:43:31Z" - content=""" -Cool!, I just tried adding tahoe-lafs as a remote, and it wasn't too hard. -"""]] diff --git a/doc/todo/wishlist:_special_remote_mega.co.nz.mdwn b/doc/todo/wishlist:_special_remote_mega.co.nz.mdwn deleted file mode 100644 index 41164084a..000000000 --- a/doc/todo/wishlist:_special_remote_mega.co.nz.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -mega.co.nz has 50gb for free accounts. They also have an API, so I guess it wouldn't be too hard to use it as a special remote. - -[[done]], see [[tips/megaannex]]. diff --git a/doc/todo/wishlist:_special_remote_mega.co.nz/comment_2_6ca08ef808d4336fc42d0f279d6627b5._comment b/doc/todo/wishlist:_special_remote_mega.co.nz/comment_2_6ca08ef808d4336fc42d0f279d6627b5._comment deleted file mode 100644 index 542b92a67..000000000 --- a/doc/todo/wishlist:_special_remote_mega.co.nz/comment_2_6ca08ef808d4336fc42d0f279d6627b5._comment +++ /dev/null @@ -1,44 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0" - nickname="Tobias" - subject="Usage of mega hook" - date="2013-05-21T09:09:28Z" - content=""" -megaannex -========= - -Hook program for gitannex to use mega.co.nz as backend - -# Requirements: - - requests>=0.10 - pycrypto - -Credit for the mega api interface goes to: https://github.com/richardasaurus/mega.py - -## Install -Clone the git repository in your home folder. - - git clone git://github.com/TobiasTheViking/megaannex.git - -This should make a ~/megannex folder - -## Setup -Run the program once to make an empty config file - - cd ~/megaannex; python2 megaannex.py - -Edit the megaannex.conf file. Add your mega.co.nz username and password - -Note: The folder option in the megaannex.conf file isn't yet used. - -## Commands for gitannex: - - git config annex.mega-store-hook '/usr/bin/python2 ~/megaannex/megaannex.py store --subject $ANNEX_KEY --file $ANNEX_FILE' - git config annex.mega-retrieve-hook '/usr/bin/python2 ~/megaannex/megaannex.py getfile --subject $ANNEX_KEY --file $ANNEX_FILE' - git config annex.mega-checkpresent-hook '/usr/bin/python2 ~/megaannex/megaannex.py fileexists --subject $ANNEX_KEY' - git config annex.mega-remove-hook '/usr/bin/python2 ~/megaannex/megaannex.py delete --subject $ANNEX_KEY' - git annex initremote mega type=hook hooktype=mega encryption=shared - git annex describe mega \"the mega.co.nz library\" - -"""]] diff --git a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y.mdwn b/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y.mdwn deleted file mode 100644 index b4f966abb..000000000 --- a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -I'd like to be able to: - - git annex copy --from=x --to=y . - -Use case (true story) follows: - -My desktop hard drive was filling up. I dropped some large files which are also stored (via git-annex) on my backup drive. While these aren't irreplaceable files, I'd prefer to have at least two copies of everything I've decided I care enough about to archive. Later, I get a 2nd external drive, and I: - - git annex copy --to=new-external-drive . - -Fantastic! Now I've got everything that was important/useful enough to keep on my desktop backed up a 2nd time onto my new drive. - -But my new drive doesn't have a copy of any of the files I dropped from my desktop. I would like to be able to: - - git annex copy --from=old-external-drive --to=new-external-drive . - -on my desktop, and then my new drive would have a copy of everything, and my desktop drive would still have plenty of space (ie the files I'd dropped to make space would still not be stored on the desktop). - -The git repos on these external drives are both bare (as in ``git init --bare``) because they are used only for backups. Thus I operate on them only as remotes from my main (desktop) repo. - -> I have now implemented the --all option, and it's the default when -> running `git annex get` inside a bare repo. -> -> So, the solution is to `cd` to the repository on old-external-drive, -> and `git remote add newdrive /path/to/new/drive/repo`. Then run `git -> annex copy --all --to newdrive` and it'll move everything. -> -> Calling this [[done]] unless there are other use cases where the double -> copy method is really needed? --[[Joey]] diff --git a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_1_cf8e0f16b723516374c95a93e4da42fc._comment b/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_1_cf8e0f16b723516374c95a93e4da42fc._comment deleted file mode 100644 index cee50a345..000000000 --- a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_1_cf8e0f16b723516374c95a93e4da42fc._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.193" - subject="comment 1" - date="2013-06-30T17:43:50Z" - content=""" -A reasonable use case indeed. - -It seems to me that [[add_-all_option]] could also satisfy this use case, as then you could run `git annex get --all` in the new bare remote. - -That would have the benefit of not doing a double copy. -"""]] diff --git a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_2_d35359c9dd4dd4365d9a7caf695ff833._comment b/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_2_d35359c9dd4dd4365d9a7caf695ff833._comment deleted file mode 100644 index 8305679a3..000000000 --- a/doc/todo/wishlist:_support_copy_--from__61__x_--to__61__y/comment_2_d35359c9dd4dd4365d9a7caf695ff833._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://jasonwoof.com/" - nickname="JasonWoof" - subject="thanks, good enough for now." - date="2013-07-15T19:27:58Z" - content=""" -the ``--all`` option works for this use case. That takes care of my problem. Thank you! - -I can imagine other use cases where I'd want ``--from`` and ``--to`` at once, such as: - -1. same situation with my two bare external drives, but I want to only copy my audio-book collection to the new drive, and not my movies. - -2. I've got a large online storage (eg rsync.net) and want copy everything from there onto my new external drive. - -I leave it up to your good judgement when/if this is worth doing. -"""]] diff --git a/doc/todo/wishlist:_support_drop__44___find_on_special_remotes.mdwn b/doc/todo/wishlist:_support_drop__44___find_on_special_remotes.mdwn deleted file mode 100644 index 24cacbf71..000000000 --- a/doc/todo/wishlist:_support_drop__44___find_on_special_remotes.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -Currently there is no way to drop files, or list what files are available, on a special remote. -It would be good if "git annex drop" and "git annex find" supported the --from argument. - -> I agree, drop should support --from. ->> [[done]] --[[Joey]] -> -> To find files *believed* to be present in a given remote, use -> `git annex find --in remote` -> Note that it might show out of date info, since it does not actually go -> check the current contents of the remote. The only reason to support -> `find --from` would be to always check, but I don't think that's needed. -> --[[Joey]] - -For commands that don't support the --from argument, it would also be nice to print an error. -Currently running "git annex drop --from usbdrive" doesn't behave as hoped and instead drops -all content from the local annex. - -> This is done now. --[[Joey]] diff --git a/doc/todo/wishlist:_support_drop__44___find_on_special_remotes/comment_1_f11ed642a83d965076778a162f701e84._comment b/doc/todo/wishlist:_support_drop__44___find_on_special_remotes/comment_1_f11ed642a83d965076778a162f701e84._comment deleted file mode 100644 index 6028933b4..000000000 --- a/doc/todo/wishlist:_support_drop__44___find_on_special_remotes/comment_1_f11ed642a83d965076778a162f701e84._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-10-27T17:13:43Z" - content=""" -Well, I don't think you mean \"special remotes\", but just any old remote (special or not). -"""]] diff --git a/doc/todo/wishlist:_support_for_more_ssh_urls_.mdwn b/doc/todo/wishlist:_support_for_more_ssh_urls_.mdwn deleted file mode 100644 index 55b8120a7..000000000 --- a/doc/todo/wishlist:_support_for_more_ssh_urls_.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -git-annex does not seem to support all kinds of urls that git does. - -Specifically, if I have ~/bar set up on host foo: - - [remote "foo"] - ## this one is not recognized as ssh url at all - # url = foo:bar - ## this one makes git-annex try to access '/~/bar' literally - # url = ssh://foo/~/bar - ## this one works - url = ssh://foo/home/tv/bar - -> scp-style is now supported. - -> `~` expansions (for the user's home, or other users) -> are somewhat tricky to support as they require running -> code on the remote to lookup homedirs. If git-annex grows a -> `git annex shell` that is run on the remote side -> (something I am [[considering|todo/git-annex-shell]] for other reasons), it -> could handle the expansions there. --[[Joey]] - -> Update: Now `~` expansions are supported. [[done]] diff --git a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository.mdwn b/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository.mdwn deleted file mode 100644 index 33c38046e..000000000 --- a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -It would be nice to have a simple command that can safely turn a plain directory into a git-annex direct repository. - -This is the use case: - -* I use git-annex to manage a directory full of files, including many huge files. -* These files are also stored in an S3 repository. -* It takes days to download those files. -* I have another computer with a directory that contains 80% of these files. -* I would like to turn that directory into a git-annex repository. -* I would like to download only the 20% missing files. - -What I would like to have a command that turns that directory into a direct repository without dealing with the gory details I will describe later. This command could be something like - - $ cd Documents - $ git annex setup --direct example.org:~/annex/Documents.git - -This command should take care of: - -* cloning the git repository `example.org:~/annex/Documents.git` to `.git`, -* switching to direct mode (carefully setting up all the needed branches), -* create symlinks _only_ for the missing files, -* record that the existing files are present in this repository. - -These are just the main problems that one faces in this task; they are mostly caused by the fact that the repo is in direct mode. - -There are workarounds, like those sketched at <http://unix.stackexchange.com/questions/75557/init-gix-annex-additional-repo-with-existing-files>, but they are all time-consuming and fragile. - -> Closing since there is a documented procedure for this -> and I don't think it can be usefully simplified to a single command. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_1_d48a98bad77400bd8384300e324d999f._comment b/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_1_d48a98bad77400bd8384300e324d999f._comment deleted file mode 100644 index ff173347f..000000000 --- a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_1_d48a98bad77400bd8384300e324d999f._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://id.koumbit.net/anarcat" - ip="72.0.72.144" - subject="comment 1" - date="2014-04-25T13:28:18Z" - content=""" -take a look at [[tips/migrating_two_seperate_disconnected_directories_to_git_annex]]. it's not a single command, granted, but it should be simple enough for your use case... -"""]] diff --git a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_2_1a1d15531c74eb0cc09f81dc09d95d39._comment b/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_2_1a1d15531c74eb0cc09f81dc09d95d39._comment deleted file mode 100644 index c250e2d22..000000000 --- a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_2_1a1d15531c74eb0cc09f81dc09d95d39._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://svario.it/gioele" - nickname="gioele" - subject="comment 2" - date="2014-04-25T19:01:06Z" - content=""" -That guide does not work for direct repositories. As soon as you switch to direct mode you cannot import the old data without jumping through hoops. - -The fact that these guide exist at all is a symptom that this is a widespread problem. Having a command in `git-annex` would be very handy and easy to use. -"""]] diff --git a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_3_66ceb7c793a2dbbd755b9595a2199aca._comment b/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_3_66ceb7c793a2dbbd755b9595a2199aca._comment deleted file mode 100644 index fbc52c5e2..000000000 --- a/doc/todo/wishlist:_turn_a_directory_into_a_git-annex_direct_repository/comment_3_66ceb7c793a2dbbd755b9595a2199aca._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.114" - subject="comment 3" - date="2014-04-27T00:05:58Z" - content=""" -I don't see a single thing that direct mode makes harder in this situation. Every command in the linked tip will work in direct mode AFAICS. -"""]] diff --git a/doc/todo/wishlist:_vicfg_possible_repo_group_names.mdwn b/doc/todo/wishlist:_vicfg_possible_repo_group_names.mdwn deleted file mode 100644 index e30cc619a..000000000 --- a/doc/todo/wishlist:_vicfg_possible_repo_group_names.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -git annex vicfg should display valid repository group names - -For trust levels the possible values are displayed: - - # Repository trust configuration - # (Valid trust levels: trusted semitrusted untrusted dead) - ... - -The same is not currently done for repository groups - - # Repository groups - # (Separate group names with spaces) - -Thanks. - -> [[done]] --[[Joey]] |