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-04-17 14:31:08 -04:00
commit 797af48f24
7 changed files with 159 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 1"
date="2014-04-17T17:25:29Z"
content="""
That error message is a git error message (from git's `wrapper.c`), not a git-annex error message.
It's quite possible that git does not scale to as many file on Windows as it does on Unix, and git is known to not scale particularly well to vast numbers of files even on unix, although running out of memory is not the typical failure mode there.
I think you should file a bug report on git.
"""]]

45
doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn Normal file
View file

@ -0,0 +1,45 @@
### Please describe the problem.
umask is 022 on both hosts
If one does ls -lL on source repo, the files are shown 644.
Now, "git annex get" from a clone done over ssh generally preserves 644 ... except if the transfer (rsync) is interrupted, and then resumed.
In fact, looks like the temp files in .git/annex/tmp have the og+r bits cleared during the resumed transfer.
So this is inconsistent: I don't see why permissions should be different, depending whether or not there was an interruption in the transfer.
Plus, og+r permissions can actually be important for setups like serving contents using Samba.
### What steps will reproduce the problem?
cd dir1
git init
git annex init
touch a
truncate -s 10G b
git annex add .
git commit -m 'new'
git clone localhost:/path/to/dir1 dir2
cd dir2
git annex get
ctrl^c
git annex get
ls -lL
... see different perms
### What version of git-annex are you using? On what operating system?
git-annex version: 5.20140411-gda795e0
Linux
### 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.
"""]]

13
doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
nickname="Georg"
subject=" remotedaemon in pre-built tarballs"
date="2014-04-17T07:40:25Z"
content="""
Hi Joey,
can you tell me when the pre-built Linux tarballs will include the remotedaemon?
Are they updated on a daily basis?
Best regards, Georg
"""]]

8
doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://id.clacke.se/"
nickname="Claes"
subject="comment 3"
date="2014-04-17T14:04:31Z"
content="""
Yeah, git does not have the concept of checking out subdirectories that subversion does. You could, however, have different branches with different content that live in the same repo and therefore share the same git-annex backend, so there could be overlap between what files are in what branch without them using up much extra disk space.
"""]]

72
doc/forum/sync_stages_deletions_on_remote.mdwn Normal file
View file

@ -0,0 +1,72 @@
I'm having an issue with 2 repos: one on my laptop, the other on my NAS. Both are in indirect mode, running Arch Linux, and have the latest Git version. Laptop has git-annex 5.20140411-gda795e0, NAS has 5.20140319-g9aa31b7 (from prebuilt tarballs).
The issue is quite simple. When I `git-annex add` new files on my laptop, commit them, and then `git-annex sync` them, they show up as staged for deletion on my NAS.
laptop $ git annex add some-file
laptop $ git commit -m "Add some-file"
laptop $ git annex sync
commit ok
pull ds413j
ok
push ds413j
Counting objects: 133, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (78/78), done.
Writing objects: 100% (80/80), 10.64 KiB | 0 bytes/s, done.
Total 80 (delta 12), reused 0 (delta 0)
To ssh://**/**
1dcd188..8ef4249 git-annex -> synced/git-annex
c0f45a6..21711d6 master -> synced/master
ok
laptop $ ssh $NAS
nas $ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: some-file
nas $
If I run `git annex sync` on the NAS, it will create a new commit that deletes that file. So I have to play with `git reset`/`git checkout` by hand to make sure that the new file won't be deleted.
I'm not sure when this started, but I think it was after I did some stupid mistake (`git checkout -B master synced/master`, kill a `git annex sync` with Ctrl+C, or something else that even resulted in my non-bare repo to have "bare=true" in .git/config...). And I haven't yet been able to fix this.
Any idea what can have caused this, how to fix it, and how to prevent it from happening again in the future?
.git/config on NAS:
[core]
repositoryformatversion = 0
filemode = true
logallrefupdates = true
[annex]
uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
version = 5
diskreserve = 1 megabyte
autoupgrade = ask
debug = false
.git/config on laptop:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
[annex]
uuid = f20cb506-945d-4c78-af1a-0aa884bb899b
version = 5
diskreserve = 20 gigabytes
autoupgrade = ask
debug = false
expireunused = 7d
genmetadata = true
[push]
default = matching
[remote "ds413j"]
url = ssh://**/**
fetch = +refs/heads/*:refs/remotes/ds413j/*
annex-uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
annex-sync = true

8
doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://schnouki.net/"
nickname="Schnouki"
subject="comment 1"
date="2014-04-17T12:16:41Z"
content="""
Here's the output of `git annex sync --debug` (for a different commit): <http://ix.io/bJZ>
"""]]

1
doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn Normal file
View file

@ -0,0 +1 @@
One problem I keep having when using a direct repo is that in order to get to the previous versions of a file you have to convert that repo to indirect and then checkout previous commits this becomes problematic when the repo in question is large conversion takes a long time and applications gets confused if there are open files from the repo as they go from actual files to symlinks. Is it possible to have a separate annex command that will checkout a previous version of a file to a different directory so we can replace/inspect it.