Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
bb1fec9c9f
13 changed files with 143 additions and 0 deletions
|
@ -121,3 +121,6 @@ local repository version: 5
|
|||
supported repository version: 5
|
||||
upgrade supported from repository versions: 0 1 2 4
|
||||
"""]]
|
||||
|
||||
|
||||
[[!taglink confirmed]] —marked as confirmed on 2018-12-30
|
||||
|
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="comment 7"
|
||||
date="2018-12-30T23:23:46Z"
|
||||
content="""
|
||||
Just tested with `7.20181106-g352f88226` on macOS 10.12.6. Archive groups work fine with v5 repo but do not work with a v7 repo. With a v7 repo content is synced, but content is never dropped from the source archive folder. If I disable assistant and run `git annex drop --auto` from the client repo this will in fact drop the files from the archive folder. With the v5 repo I get drop logs in daemon.log with the v7 repos I get no errors in the logs and also no drop logs.
|
||||
|
||||
Also reported by a user here: [https://git-annex.branchable.com/bugs/OSX_Assistant_will_not_automatically_drop/]
|
||||
"""]]
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="flpgdt@f64318f00d9e1c9535e11f5d27c80c1d799cce00"
|
||||
nickname="flpgdt"
|
||||
avatar="http://cdn.libravatar.org/avatar/df837a3ae490227608cc38a7c9edfc7a"
|
||||
subject="comment 8"
|
||||
date="2018-12-31T16:53:50Z"
|
||||
content="""
|
||||
Would that be a possible workaround? Is there a way to force git-annex to use only v5 repos?
|
||||
"""]]
|
|
@ -18,5 +18,10 @@ fatal: this operation must be run in a work tree
|
|||
6.20170818
|
||||
|
||||
|
||||
|
||||
|
||||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
Yes, I did, it works great whenever I barely use, as soon as more data comes in it messes up and data goes missing.
|
||||
|
||||
|
||||
[[done]] —resolved by poster
|
||||
|
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="Chymera"
|
||||
avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
|
||||
subject="comment 2"
|
||||
date="2018-12-30T20:47:00Z"
|
||||
content="""
|
||||
Luckily I had a backup, so I fixed this by re-adding my disappeared files with the cutting edge `cp` command.
|
||||
Most probably this ended up cluttering my history, though.
|
||||
"""]]
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="comment 3"
|
||||
date="2018-12-30T22:12:08Z"
|
||||
content="""
|
||||
OK. Glad to hear. I'll move this bug to done.
|
||||
|
||||
There are some notes on how to run git commands on a direct mode repo here: <https://git-annex.branchable.com/direct_mode/#index8h2>. I would do this on a copy of your repo though.
|
||||
|
||||
Also Joey did mention (5 years ago) that you can [switch to indirect mode to run git commands](http://git-annex.branchable.com/forum/Retrieve_previous_version_in_direct_mode/#comment-2d28e7d2f8442e2d815e7dff485a6b77). I am not sure if you would be able to switch back to direct mode with the latest git-annex though… I would do this on a copy of your repo if need be.
|
||||
"""]]
|
|
@ -0,0 +1,43 @@
|
|||
Hello,
|
||||
When doing a "git annex init somename --version=5" on git-annex 7.20181211, it still creates an v7 repository. I want to be able to use the direct-mode because of space constraints (v7 unlocked files take up double the space).
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
See the transcript below, on a vfat-Filesystem.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
7.20181211 on debian buster
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
|
||||
$ git init
|
||||
Initialized empty Git repository in /media/xxx/xxx/.git/
|
||||
$ git annex init yellow-thumbdrive --version=5
|
||||
init yellow-thumbdrive
|
||||
Detected a filesystem without fifo support.
|
||||
|
||||
Disabling ssh connection caching.
|
||||
|
||||
Detected a crippled filesystem.
|
||||
|
||||
Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
|
||||
|
||||
Switched to branch 'adjusted/master(unlocked)'
|
||||
ok
|
||||
(recording state in git...)
|
||||
$ git annex version
|
||||
git-annex version: 7.20181211
|
||||
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
|
||||
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
|
||||
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
|
||||
operating system: linux x86_64
|
||||
supported repository versions: 5 7
|
||||
upgrade supported from repository versions: 0 1 2 3 4 5 6
|
||||
local repository version: 7
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
5
doc/forum/Move_history.mdwn
Normal file
5
doc/forum/Move_history.mdwn
Normal file
|
@ -0,0 +1,5 @@
|
|||
I have recently noticed that my .git directory in one copy of my git annex repository has ballooned to about 500GB (on a direct mode network).
|
||||
|
||||
Is there any way to move the history to another repository? I guess 500GB isn't that bad on my archive repositories, but for one of my deployment machines this much space for files I don't use isn't really acceptable.
|
||||
|
||||
Alternatively, and since this repo is quite a bit older, I think I could also just delete some of the history. Is there any way to do that?
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="comment 1"
|
||||
date="2018-12-30T21:58:55Z"
|
||||
content="""
|
||||
If you run `git annex info` you can see how much of this space is from actual annexed objects `local annex size`. Anyhow if the files aren't associated with any files in your working tree and you don't want them you can remove them with the `unused` command, there are some pointers here: <http://git-annex.branchable.com/walkthrough/unused_data/>.
|
||||
"""]]
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
|
||||
nickname="chocolate.camera"
|
||||
avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
|
||||
subject="Why so slow"
|
||||
date="2018-12-31T04:06:08Z"
|
||||
content="""
|
||||
Why is uninit so slow? Shouldn’t it simply consist of moving the files out of the annex and then delete the .git folder?
|
||||
"""]]
|
|
@ -0,0 +1,11 @@
|
|||
[[!comment format=mdwn
|
||||
username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
|
||||
nickname="chocolate.camera"
|
||||
avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
|
||||
subject="comment 1"
|
||||
date="2018-12-31T16:41:08Z"
|
||||
content="""
|
||||
> Normally, unlocking a file requires a copy to be made of its content, so that its original content is preserved
|
||||
|
||||
Does that imply than, on v7 in a file system that does not support hard links such as FAT32, `git annex adjust --unlock` would effectively be creating a duplicate of all files via cp (which is incredibly costly time-wise specially for big repos and huge files) and would effectively double the size it occupies?
|
||||
"""]]
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="michael@ff03af62c7fd492c75066bda2fbf02370f5431f4"
|
||||
nickname="michael"
|
||||
avatar="http://cdn.libravatar.org/avatar/125bdfa8a2b91432c072615364bc3fa1"
|
||||
subject="Import --clean-duplicates"
|
||||
date="2018-12-31T10:40:03Z"
|
||||
content="""
|
||||
I would like to revive this request for lower-case file extensions in the SHA256E backend. At some point, I migrated all my photos to use lower-case filenames. However, the images stored on the SD card of my camera still use upper-case filenames including the extension. I would love to be able to use git annex import --clean-duplicates to remove already imported images from the SD card. However, this no longer works due to my files being directly added with lower-case extensions.
|
||||
"""]]
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="andrew"
|
||||
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
|
||||
subject="comment 3"
|
||||
date="2018-12-30T23:29:16Z"
|
||||
content="""
|
||||
Linking to another poster asking for assistant to monitor changes to `~/.git/config`
|
||||
|
||||
<https://git-annex.branchable.com/bugs/annex.autocommit_seems_ignored_for_new_files/>
|
||||
"""]]
|
Loading…
Reference in a new issue