blob: 3368e3a31dcde1fa542239cc42dacb8ab6524a21 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 2"
date="2013-06-14T15:40:04Z"
content="""
Your transcript shows `git annex get` apparently receiving the file. I don't see how that could possibly have worked if git-annex-shell were not in the path on the server, since that is the command it runs to send the file. Also, `git annex copy` is earlier used to send the file to origin, which again should not work if git-annex-shell was not in the path. I think this whole git-annex-shell not in path thing is a red herring.
What actually appears to be going on is this:
1. You create a new empty repository. Since this is Windows, it's forced into direct mode.
2. You manually merge origin/synced/master into this repository. Bypassing `git annex sync` in this way means that direct mode mappings are not updated for the files contained in that branch.
3. You run `git annex get` on a file from that branch. The file is retrieved. Since no direct mode mapping exists for the object it just retrieved, it stashes it in .git/annex/objects and the file is left with the fake symlink git uses on windows.
The manual merge in step 2 is the cause of the problem. The [[direct_mode]] documentation advises against using git commands that update the repository tree because it can lead to this kind of problem (as well as more serious data loss).
Of course, you had no choice but to merge from origin/synced/master, because git annex sync didn't push to origin/master, so simply cloning the bare repository wouldn't work. However, I did fix that a few days ago.
I see this as more evidence of there needing to be a [[todo/direct_mode_guard]] to block users from running unsafe git commands in direct mode repositories. This bug probably can be closed, assuming I correctly understand what happened.
"""]]
|
