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

This commit is contained in:
Joey Hess 2015-03-20 11:44:53 -04:00
commit dd35cf34a4
3 changed files with 73 additions and 0 deletions

View file

@ -0,0 +1 @@
Are case-insensitive searchs possible with find, list, and whereis?

View file

@ -0,0 +1,5 @@
Is there a way to use notify-start and notify-finish, not when using git annex
on the command line but also when using the assistant ?
I would like to get notifications when I move files to annexed folders for when
the transfer to the server is finished and such things.

View file

@ -0,0 +1,67 @@
[[!comment format=mdwn
username="Xyem"
subject="comment 1"
date="2015-03-20T10:51:59Z"
content="""
I just tested this and git-annex does not act according to its documentation.
## git init annex
Initialized empty Git repository in ./annex/.git/
## mkdir to_import
mkdir: created directory to_import
## echo A > annex/A
## echo B > annex/B
## echo A > to_import/A
## echo B > to_import/B
## echo C > to_import/C
## cd annex/
## git annex init
init ok
(Recording state in git...)
## git annex add .
add A ok
add B ok
(Recording state in git...)
## git commit -m \"commit\"
[master (root-commit) f2628f0] commit
2 files changed, 2 insertions(+)
create mode 120000 A
create mode 120000 B
## git annex drop B --force
drop B ok
(Recording state in git...)
Annex knows about A and B, A is present but B is not.
to_import contains A, B and C.
## git annex import --deduplicate ../to_import/
import to_import/C ok
import to_import/A (duplicate) ok
import to_import/B ok
(Recording state in git...)
## ls -R
.:
A B to_import
./to_import:
B C
According to the docs, it would look like this:
## ls -R
.:
A B to_import
./to_import:
C
and B would be a dangling symlink (due to the content having been seen by the annex before, but not present).
So '--import --deduplicate' actually imports/deduplicates files whose content /is not present/ in the annex, rather than 'has not been seen before'.
Fortunately, this error is on the side of caution and data is never lost, but you do end up with duplicates (2 symlinks pointing to the same content).
The behaviour is acceptable (to me at least, better duplicate symlinks than lost data), but the documentation is misleading and should probably refer to content presence rather than having ever been present.
"""]]