mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2014-02-17 12:24:50 -04:00
commit e640d768ed
9 changed files with 159 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
doc/bugs/fsck_giving_false_checking_information.mdwn Normal file
View file

@ -0,0 +1,27 @@
### Please describe the problem.
When a repository has no object of a given file and git annex fsck is run it still shows "fsck file ok", which is missleading in the sense, that it gives the impression that it checked the file is alright/checksummed.
As a result of this it seems that incremental fscks are not incremental with non checkable objects. On each run (after the first one) with "git annex fsck --incremental --more --schedule-limit 1d" all files without objects are checked even so it should wait another day till it checks again.
Probably best to say checksum couldn't be checked on x files (only give that as quiet output, not every check)
Another thing, which came up as a problem was, that checksum fsck would not be wanted to run as often as numcopie checks.
When the incremental fsck is used to check for bad files "git annex fsck --incremental --more --limit 1m" after a fast numcopies check "git annex fsck --incremental --more --limit 1m fast" it messes up the actual bad files check.
As both are currently using the same incremental "lock"-file they are colliding.
### What steps will reproduce the problem?
-
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140210-gd99db49
Linux (Ubuntu 13.10)
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]

10
doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="stp"
ip="188.193.207.34"
subject="Earlier version syntax was removed"
date="2014-02-17T16:05:34Z"
content="""
In earlier versions I noticed that when checksumming it would give back \"fsck file (checksum...) ok\" instead of \"fsck file ok\", which is at least better than not differentiating. This should definitely be improved. Perhaps even clearer than the (checksum...) notice.
But still the incremental run not being incremental and not taking into account the schedule-limit seems strange.
"""]]

31
doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn Normal file
View file

@ -0,0 +1,31 @@
### Please describe the problem.
When "git annex sync --content" is used only objects currently in the working tree are synced. It doesn't honor full archives, which should get all objects.
So only objects similar to "git annex find --want-get" are synced and not every available object "git annex get --all"
### What steps will reproduce the problem?
# mein repo:
git annex add file
git annex sync
git annex rm file
git annex sync
# other repo:
git annex wanted here "not copies=backup:3"
git annex find --want-get # will be empty
git annex sync --content # nothing is synced even so all files should be backed up
git annex get --all # will sync the object from file
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140210-gd99db49
Linux (Ubuntu 13.10)
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]

19
doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn Normal file
View file

@ -0,0 +1,19 @@
### Please describe the problem.
Within the walkthrough the deprecated annex.numcopies are still used. At least it should be added that "git annex numcopies x" can be used to define it globally without the need for a .gitattribute file. And use .gitattribute only for per directory and fine grained control.
http://git-annex.branchable.com/walkthrough/backups/
### What steps will reproduce the problem?
### What version of git-annex are you using? On what operating system?
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]

11
doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="https://renaud.casenave.fr/"
ip="126.10.66.235"
subject="comment 8"
date="2014-02-17T13:15:24Z"
content="""
Hi,
You might be happy to know git-annex works well on sailfishOS, even the webapp.
It does segfault when trying to setup a xmpp account, though.
"""]]

36
doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment Normal file
View file

@ -0,0 +1,36 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
nickname="Srinath"
subject="Progress, but still issues"
date="2014-02-17T04:09:23Z"
content="""
\"I now realize that the git annex system still requires the standard \"add\" and \"commit\" process. But I'm still getting:
$git annex sync
commit ok
pull origin
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 36 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (36/36), done.
From ssh://stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
* [new branch] master -> origin/master
merge: refs/remotes/origin/synced/master - not something we can merge
failed
push origin
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (8/8), 736 bytes | 0 bytes/s, done.
Total 8 (delta 3), reused 1 (delta 0)
To ssh://srinathv@stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
* [new branch] git-annex -> synced/git-annex
* [new branch] master -> synced/master
ok
git-annex: sync: 1 failed
So the fails appear, and the suggestion of \"export PATH\" placement did not help, though appreciated.
"""]]

8
doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
nickname="Srinath"
subject="no more issue"
date="2014-02-17T04:25:31Z"
content="""
After doing 1 more sync, the error messages are now gone. I wonder if the refs directory needed to be synched correctly.
"""]]

2
doc/git-annex.mdwn
View file

@ -517,7 +517,7 @@ subdirectories).
have been fscked. And once it's done, you'd like a new fsck pass to start,
but no more often than once a month. Then put this in a nightly cron job:
git annex fsck --incremental-schedule 30d --time-limit 5h
git annex fsck --incremental --more --incremental-schedule 30d --time-limit 5h
To verify data integrity only while disregarding required number of copies,
use `--numcopies=1`.

16
doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn
View file

@ -37,3 +37,19 @@ in my opinion, the messages should at least contain
>> 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]]