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

This commit is contained in:
Joey Hess 2017-01-08 17:03:47 -04:00
commit 1f12a20db6
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
5 changed files with 85 additions and 0 deletions

View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="t.z.mates"
avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925"
subject="comment 5"
date="2017-01-08T06:43:48Z"
content="""
So, I've done a bit more investigating, and it seems the specific command that causes the error is
git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo
In particular, if I execute the code:
git init
git annex init --version=6
mkdir -p 1/2/3/4
touch 1/2/3/4/foo
git annex add 1/2/3/4/foo
git annex sync
git annex unlock 1/2/3/4/foo
echo \"bar\" >> 1/2/3/4/foo
cd 1/2/3/4
git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo
I get the above mentioned error. However, if I run the exact same code without any of the \"git annex\" commands (i.e. only initializing a standard git repository), the ls-files commands returns without error.
I'm not sure what to make of this though; it doesn't seem to be any sort of corrupted log or bad config options (I ran the same commands on a different, working computer, copied the .git directory to the non-working computer, and still couldn't run the ls-files command). I'm rather at a loss of what to check next.
"""]]

View file

@ -0,0 +1,17 @@
Working on the Baobáxia project, we have this interesting problem: If some content is added twice with different file names, it will appear in the git-annex repository as two symlinks pointing to the same file in the annex.
So far so good.
But this means that if I want to delete a file, I have two cases:
* If this content was added only once, I need to drop the binary content with git annex drop and afterwards remove the symlink with git rm.
* If this content exists under more than one file name, I need to remove the symlink with git rm only; I should *not* drop the content.
So the question is: How do I know that, apart from searching through the whole repository? Is there a more efficient way? After going through the manual I can't find it, but I may have overlooked something.
Best regards and TIA for any response
Carsten Agger
Note: This question references bug #191 in the Baobáxia project, https://github.com/RedeMocambos/baobaxia/issues/191

View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="ghen1"
avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
subject="comment 1"
date="2017-01-07T15:41:36Z"
content="""
You don't need to keep track of links. Just delete the links, then run:
git-annex unused
This will find any content that isn't linked to. You can then run *git-annex dropunused* to free up space.
See these man pages:<br/>
<https://git-annex.branchable.com/git-annex-unused/><br/>
<https://git-annex.branchable.com/git-annex-dropunused/>
"""]]

View file

@ -0,0 +1,12 @@
Hi,
I was wondering whether it was possible to configure git annex in a way, that new content is held in a specific repository until it is considered old.
I found that "git config annex.genmetadata true" creates year and month tags in the metadata. However, creating the wanted expression poses a problem. Afaik there is no way to access the current year/month in a wanted expression and no way to do arithmetic in a wanted expression. Furthermore, I do not know, when the assistant checks wanted expressions for matches? I assume it does so only when something changes in git or when the wanted expressions change but not in regular intervals?
I guess I could whip up a cronjob that changes the wanted expression every month and do the calculations outside of git annex but this seems somehow wrong.
Is this a problem other users share or maybe have already solved?
Cheers,
Marek

View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="fossil"
avatar="http://cdn.libravatar.org/avatar/951f4f4e1dca2ebe880ddb392c2d3e73"
subject="comment 4"
date="2017-01-08T15:57:42Z"
content="""
This is a bug, introduced in [commit 34530e59](https://github.com/joeyh/git-annex/commit/34530e59) (release 6.20161012) and fixed in [commit b530e432](https://github.com/joeyh/git-annex/commit/b530e432) (release 6.20161031).
* [git-annex chokes on filenames including spaces](https://git-annex.branchable.com/bugs/git-annex_chokes_on_filenames_including_spaces/)
* [Single space in file name causes git annex add to fail](https://git-annex.branchable.com/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/)
It happens only when the filename contains a single space, so a workaround is to first add a filename without any spaces, and then rename it:
fn=\"foo bar.txt\"; cp \"$fn\" tmp && git annex add tmp && git mv -f tmp \"$fn\"
"""]]