bug triage; add new 'confirmed' tag
This commit is contained in:
parent
476f52ef41
commit
fb20f6829d
63 changed files with 116 additions and 2 deletions
|
@ -3,3 +3,5 @@ I’m running git-annex 5.20140517-gee56d21 on Android 4.3.
|
|||
A number of icons seem to be missing since the bootstrap3 update:
|
||||
|
||||
<img src="http://heh.fi/tmp/git-annex-missing-icons.png" alt="git-annex missing icons" width="540">
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -1,22 +0,0 @@
|
|||
Note: This may not be a bug maybe the software doesn't work the way I think.
|
||||
|
||||
What steps will reproduce the problem?
|
||||
|
||||
Using the webapp, I created a normal repo on my desktop. I then added a 'Removable drive' repo on my usb stick.
|
||||
|
||||
I want all my files to be synced and accessibles on both repos so I set the 'Removable drive' repo to 'client'.
|
||||
|
||||
|
||||
What is the expected output? What do you see instead?
|
||||
|
||||
When I look in the 'annex' folder on my usb stick. I see a git repo (annex, branches, hooks) instead of seeing the files in the same way the 'annex' repo on my desktop is.
|
||||
|
||||
|
||||
What version of git-annex are you using? On what operating system?
|
||||
|
||||
I'm using 9e57edff287ac53fc4b1cefef7271e9ed17f2285 (Fri Feb 22 15:19:25 2013 +0000).
|
||||
|
||||
Ubuntu 12.10 x86_64
|
||||
|
||||
[[!tag /design/assistant]]
|
||||
[[!meta title="assistant should set up non-bare repos on removable drives, and update them when syncing with them"]]
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="4.153.253.75"
|
||||
subject="comment 1"
|
||||
date="2013-02-22T21:46:59Z"
|
||||
content="""
|
||||
You have a bare git repository on your USB stick. The assistant uses bare repositories on USB sticks currently, although recent changes to support FAT make it possible to use non-bare repositories.
|
||||
|
||||
For this to really work the way you want it to, the assistant would need to start updating local non-bare repositories whenever it pushed changes to them. Currently the assistant only updates the repository it's running in, so a non-bare repository on USB would lag behind and show an old version of the directory until manually updated with `git annex sync`.
|
||||
"""]]
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Xyem"
|
||||
ip="87.194.19.134"
|
||||
subject="comment 2"
|
||||
date="2013-02-27T00:02:01Z"
|
||||
content="""
|
||||
Struggling to get the assistant to behave properly, including a similar situation to the above.
|
||||
|
||||
I start the assistant with 'git annex webapp' and create an annex from the webapp.
|
||||
Adding an SSH remote (even if just a different directory on localhost) with \"Remote server\", creates the remote directory with what looks like what the contents of .git should be (annex, branches, hooks, objects etc.), regardless of the group chosen.
|
||||
|
||||
Judging from your above comment, this means it is creating a bare repository. Why would it be doing this for an SSH remote, where git-annex-shell is available?
|
||||
|
||||
System: Arch Linux
|
||||
git-annex version: 3.20130216
|
||||
Installed with: yaourt -S git-annex-bin
|
||||
"""]]
|
|
@ -1,11 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://edheil.wordpress.com/"
|
||||
ip="173.162.44.162"
|
||||
subject="comment 3"
|
||||
date="2013-02-27T01:12:29Z"
|
||||
content="""
|
||||
Xyem, if you use git to clone a repo, instead of letting the assistant do it for you, you can get a non-bare repo. See the walkthrough for some examples. You can keep its working tree up to date with \"git annex sync\" run in that directory.
|
||||
|
||||
Only helpful if you don't mind using git annex at the command line, I know.
|
||||
|
||||
"""]]
|
|
@ -1,21 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Xyem"
|
||||
ip="87.194.19.134"
|
||||
subject="comment 4"
|
||||
date="2013-02-27T12:16:45Z"
|
||||
content="""
|
||||
@edheil:
|
||||
Yes, I have found that creating the repositories outside of the assistant (or directly on each machine through the assistant) and adding the remotes manually doesn't have this issue.. but as I am not setting this up for myself, so dropping to the command line is an issue (she's not averse to it, but also isn't a power user).
|
||||
|
||||
It seems that the assistant/webapp is replacing dropbox functionality, while ignoring the functionality of git-annex. Perhaps I am misunderstanding the goal of it..?
|
||||
|
||||
My intended use case in the situation where this issue comes up is:
|
||||
|
||||
Repository on desktop has a copy of all files in indirect mode.
|
||||
Repository on netbook only has a copy of files added locally or fetched manually.
|
||||
Dropping a file in the netbook annex should cause it to be uploaded to the desktop repository (when it is available). Files should be fetchable/droppable (and unlockable) using the webapp from the desktop/netbook repository respectively.
|
||||
|
||||
But it looks like this is (currently) unachievable as the webapp provides no method of fetching/dropping files, the assistant does not create the remote repositories correctly and requires dropping to the command line if worked around. Eep!
|
||||
|
||||
Hope this doesn't come off as sour complaining. I was introduced to git-annex by a friend about a week ago (she only learned about it about 2-3 weeks ago and *loves* it) and it is a very nice and flexible tool which fits my own use case perfectly, meeting and exceeding every expectation.. until it came to the assistant and webapp (which makes me wonder why Joey is working on an Android port..).
|
||||
"""]]
|
|
@ -1,12 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://edheil.wordpress.com/"
|
||||
ip="173.162.44.162"
|
||||
subject="comment 5"
|
||||
date="2013-02-27T17:05:07Z"
|
||||
content="""
|
||||
There is a way to fetch/drop files if you don't want to use the command line, though it's not nearly as flexible as using a command line. If you've got a machine set as \"client\" then dragging files into a subdirectory named \"archive\" drops them, and dragging them out of that subdirectory fetches them.
|
||||
|
||||
Honestly, moving files in and out of directories, and preferred content settings, have both been subject to the occasional regression, so there have been times this hasn't worked right, but in theory, that's how you do it.
|
||||
|
||||
Unfortunately if you've got more than one \"client\" machine, this means adding/dropping files on one will affect them all, as file movements propagate.
|
||||
"""]]
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://edheil.wordpress.com/"
|
||||
ip="173.162.44.162"
|
||||
subject="comment 6"
|
||||
date="2013-02-27T17:06:45Z"
|
||||
content="""
|
||||
also... I've never used the feature where you have two local machines running git-annex and you tell one to share a repo with the other through the web interface, but maybe it would be helpful for this scenario? Apologies if you've already tried that.
|
||||
"""]]
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 7"
|
||||
date="2013-02-27T17:43:45Z"
|
||||
content="""
|
||||
The way this is supposed to (and does) work is that you use the webapp to create a repository on each computer, and then you pair them together using either local pairing or xmpp pairing.
|
||||
|
||||
Today's release of git-annex also adds UI in the webapp to create additional local repositories that are connected to the current repository. However these are not really intended to be put on removable drives since the assistant needs to be running on them to keep them up-to-date.
|
||||
"""]]
|
|
@ -1,16 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="Xyem"
|
||||
ip="87.194.19.134"
|
||||
subject="comment 8"
|
||||
date="2013-02-27T18:36:16Z"
|
||||
content="""
|
||||
@Joey:
|
||||
As my use case is 1 person using multiple machines, I didn't think local/XMPP pairing was appropriate.
|
||||
|
||||
Local pairing because the netbook leaves the network the desktop machine is on, which is when transferring the files is wanted (otherwise, they would just use the desktop...).
|
||||
XMPP pairing description implies that it is for 2 different people (thus 2 different addresses). Can it be used where both annexes are using the same address? Or does the address also allow you to include the location (i.e. name@host.com/netbook)?
|
||||
|
||||
It definitely sounds like I am misunderstanding how this is supposed to work so I apologise for that. Please keep up the excellent work. git-annex is one of those tools I wish I had learned about a long time ago!
|
||||
|
||||
@edheil: Interesting workaround, thanks.
|
||||
"""]]
|
|
@ -1,10 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://id.koumbit.net/anarcat"
|
||||
ip="72.0.72.144"
|
||||
subject="confusing..."
|
||||
date="2014-05-14T05:04:01Z"
|
||||
content="""
|
||||
this is still really confusing. having to create the repo by hand is a really confusing step - i have setup an external drive to have my files with me as i move around, having to go through hoops to find them in a bare repository seems contrary to the spirit of \"future proofing\" inherent to git annex.
|
||||
|
||||
the solution i found was to `git init` the repo on the removable drive before adding it through the webapp. i hope this can eventually be fixed, as it led to confusion among many other users (e.g. [[forum/Accessing_files_in_bare_repository/]], [[bugs/Adding a repository as a \"remote server\" creates a bare repository next to the existing one/]], [[forum/remote server client repositories are bare!?/]] and so on). --[[anarcat]]
|
||||
"""]]
|
|
@ -32,3 +32,6 @@ STR:
|
|||
You can't simply do `git annex add repo` because that will ignore the .git directory. Similarly,` git annex add .git` (which I'd think really should try to add the contents of the .git directory) ignores everything.
|
||||
|
||||
I don't know what this error means. Is there a right way to work around this?
|
||||
|
||||
> [[meta title="cannot add .git/ to a git repository. even when using git-annex."]]
|
||||
> [[confirmed]] (but may be out of scope for git-annex) --[[Joey]]
|
||||
|
|
|
@ -24,3 +24,5 @@ and the repository exists.
|
|||
"""]]
|
||||
|
||||
[[!meta title="xmpp syncing sometimes fails"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -16,3 +16,4 @@ What version of git-annex are you using? On what operating system?
|
|||
Please provide any additional information below.
|
||||
|
||||
[[!tag /design/assistant]]
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -30,3 +30,7 @@ Description: Ubuntu 12.04.2 LTS
|
|||
Release: 12.04
|
||||
Codename: precise
|
||||
"""]]
|
||||
|
||||
[[!meta title="git-annex does not guarantee modified files are available when merging with a new version of a repository"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -22,3 +22,4 @@ Instead, it begins syncing the files to the server but prompts for a GPG passpha
|
|||
Not sure if I'm just missing a setting for GPG, but I would think I should only need to use the web app to configure the remote server.
|
||||
|
||||
[[!tag /design/assistant]]
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -61,3 +61,5 @@ I tried playing with making the repository direct and then indirect, hoping that
|
|||
Linux konixwork 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -14,3 +14,5 @@ Karsten
|
|||
> same content. It doesn't loop like it did in direct mode, only
|
||||
> happens once (or once per duplicate file, really). Is still potentially
|
||||
> annoying and a bug. --[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -123,3 +123,4 @@ Codename: precise
|
|||
"""]]
|
||||
|
||||
|
||||
> [[confirmed]] (but may be out of scope for git-annex) --[[Joey]]
|
||||
|
|
|
@ -17,3 +17,4 @@ Please provide any additional information below.
|
|||
|
||||
The man page lists how to configure rate limiting for rsync, not sure how to do it for this
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -24,3 +24,4 @@ To be precise, I suspect that the kqueue limit is 256, I had 325 files in the 'q
|
|||
> since we use FSEvents there instead. --[[Joey]]
|
||||
|
||||
[[!tag /design/assistant]]
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -173,3 +173,5 @@ fatal: The remote end hung up unexpectedly
|
|||
ssh: connect to host Inspiron-14z.local port 22: Connection refused
|
||||
fatal: The remote end hung up unexpectedly
|
||||
"""]]
|
||||
|
||||
[[moreinfo]]
|
||||
|
|
|
@ -12,3 +12,5 @@ Yes, there is an argument to be made that this is too much hand-holding, but I s
|
|||
> as it is to undo any other git commit, right? I quite like that git-annex
|
||||
> no longer adds any clutter to the master branch, and would be reluctant
|
||||
> to change that. --[[Joey]]
|
||||
|
||||
[[wontfix|done]] --[[Joey]]
|
||||
|
|
|
@ -16,3 +16,4 @@ What version of git-annex are you using? On what operating system?
|
|||
Please provide any additional information below.
|
||||
|
||||
I don't use networkmanager if proxy information is obtained from it. There should be a fallback to environment variables.
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -25,3 +25,4 @@ What version of git-annex are you using? On what operating system?
|
|||
|
||||
[[!meta title="webapp does not allow disabling encryption on rsync special remotes"]]
|
||||
[[!tag /design/assistant]]
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -12,3 +12,4 @@ resend the data if S3 sends it a 307 redirect. --[[Joey]]
|
|||
At least the send leak should be fixed by the patch in the s3-memory-leak
|
||||
branch in git. That needs a patch to hS3, which I have sent to its author.
|
||||
--[[Joey]]
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -51,3 +51,4 @@ Please provide any additional information below.
|
|||
supported repository versions: 3
|
||||
upgrade supported from repository versions: 0 1 2
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -98,3 +98,5 @@ add music/Pop/Various/Like, Omigod! The 80s Pop Culture Box (totally)/._4-08 Tal
|
|||
"""]]
|
||||
|
||||
[[!meta title="direct mode mappings scale badly with thousands of identical files"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -111,3 +111,5 @@ To add insult to injury, this does "work":
|
|||
> add`. I originally wrote git-annex import just to avoid needing to run
|
||||
> those 2 commands myself, and I can make my own local shell script
|
||||
> to do that... --[[Joey]]
|
||||
|
||||
>> Well, I guess skipping .git is enough. [[done]] --[[Joey]]
|
||||
|
|
|
@ -14,3 +14,5 @@ put this in your git annex config in the particular remote's section:
|
|||
annex-rsync-options = -e /local/path/to/your/repo/.git/ssh
|
||||
|
||||
(typical bug report information: observed with git-annex 3.20121127 on debian)
|
||||
|
||||
> [[done]]; see my comment --[[Joey]]
|
||||
|
|
|
@ -1 +1,5 @@
|
|||
In a true dropbox-like fashion, I tried to import my entire homefolder into the git-annex assistant. However, it seems that git-annex breaks on the several git repositories I've got checked out in my "Projects" folder. Is this a possible use case, or should I look at other tools to perform this with?
|
||||
|
||||
> [[done]]; use a tarball or see extensive discussion here:
|
||||
> <http://git-annex.branchable.com/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/>
|
||||
> --[[Joey]]
|
||||
|
|
|
@ -6,3 +6,5 @@ Mac OS 10.7 version 2013-09-10
|
|||
[[!meta title="assistant does not interoperate with gitolite when adding a repository"]]
|
||||
|
||||
[2013-09-13 17:00:55 CEST] chat: ssh ["-p","22","git@example.org","sh -c 'mkdir -p '\"'\"'my-annex.git'\"'\"'&&cd '\"'\"'my-annex.git'\"'\"'&&if [ ! -d .git ]; then git init --bare --shared; fi&&git annex init'"]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -14,3 +14,5 @@ temporarily.
|
|||
[[!tag /design/assistant]]
|
||||
|
||||
--[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -28,3 +28,5 @@ Description: Ubuntu 12.04.2 LTS
|
|||
Release: 12.04
|
||||
Codename: precise
|
||||
"""]]
|
||||
|
||||
> [[confirmed]] (but may be out of scope) --[[Joey]]
|
||||
|
|
|
@ -43,3 +43,5 @@ Description: Ubuntu 12.04.2 LTS
|
|||
Release: 12.04
|
||||
Codename: precise
|
||||
"""]]
|
||||
|
||||
> [[confirmed]] (but may be out of scope) --[[Joey]]
|
||||
|
|
|
@ -26,3 +26,5 @@ upgrade supported from repository versions: 0 1 2 4
|
|||
"""]]
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -17,3 +17,5 @@ ssh key when they cannot be. --[[Joey]]
|
|||
> After recent sshpassword changes, the webapp sets up a dedicated ssh key
|
||||
> by default. If the user chooses to use an existing ssh key, it will be
|
||||
> used. So this is less likely to be a problem. --[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
8
doc/bugs/confirmed.mdwn
Normal file
8
doc/bugs/confirmed.mdwn
Normal file
|
@ -0,0 +1,8 @@
|
|||
These bug reports have been confirmed to be real bugs, and so are likely
|
||||
to be the next bugs fixed.
|
||||
|
||||
If your bug report is not listed here, you probably need to provide more
|
||||
information so that the bug can be reproduced.
|
||||
|
||||
[[!inline pages="./* and link(./confirmed) and !link(./done) and !*/Discussion" sort=mtime show=10
|
||||
archive=yes]]
|
|
@ -25,3 +25,5 @@ OS X lion (10.7)
|
|||
I wasn't logging when this happened.
|
||||
|
||||
Again, just a heads-up; I'll keep my eye open for this happening again and post more info if it does.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -26,3 +26,5 @@ Current.
|
|||
"""]]
|
||||
|
||||
[[!meta title="upgrade loop when info file contains newer version than distributed version of git-annex"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -20,3 +20,5 @@ Latest release on MS Windows.
|
|||
Installing git creates read-only directories that cannot be used by the
|
||||
git-annex install afterwards. Without admin rights, the read-only flag of
|
||||
the git dir cannot be altered.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -14,3 +14,5 @@ Running git-annex merge shows the output "git-annex merge ", followed by a blink
|
|||
dtruss output at https://www.dropbox.com/s/4b3yqn7ajfz5el2/annex-merge.log
|
||||
|
||||
[[!meta title="no indication when git-annex is stuck waiting for a lock"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -45,3 +45,5 @@ I'm fairly unsure where to look for the cause and what logs to provide you with
|
|||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
[[!tag moreinfo]]
|
||||
|
|
|
@ -26,3 +26,5 @@ repositories. Is «git annex add» the intended way of doing so?
|
|||
### What version of git-annex are you using? On what operating system?
|
||||
git-annex 5.20140421
|
||||
Linux 3.14.3
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -29,3 +29,5 @@ Linux (Ubuntu 13.10)
|
|||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -33,3 +33,5 @@ I'd like to use the skip-worktree scheme in order to be able to rm the symlink f
|
|||
I did a little digging in the code, and it looks like the source of this is the stageDirect step done specifically by `git annex sync` in direct repos (which makes sense, since indirect repos work). It does `git ls-files --others --exclude-standard --stage`. This list includes files marked skip-worktree, which means skip-worktree files would be treated like normal, and deleted because it's no longer there. There is an additional `-t` argument that could be added to ls-files that would provide the tag field to indicate if a file was marked skip-worktree, and they could be filtered out of processing.
|
||||
|
||||
I wonder if this would have side effects, or if there are other places in the code where skip-worktree files would need to be handled, though. I'm particularly motivated to solve this, so let me know if it doesn't look like it would get looked at right away, and I'll have an excuse to get a Haskell dev environment setup again and shake the rust off.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -11,3 +11,4 @@ is committed. This would mean that a commit would result in new staged
|
|||
changes for another commit, which is perhaps startling behavior.
|
||||
|
||||
The other way to fix it is to stop using symlinks, see [[todo/smudge]].
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -12,3 +12,5 @@ I've discussed with glacier-cli's author making git-annex store enough info
|
|||
in its branch to be able to bootstrap glacier-cli to know about a file.
|
||||
This seems doable and he had a design; waiting on movement
|
||||
on the glacier-cli side.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -220,3 +220,5 @@ To git@bitbucket.org:waltersom/Pictures.git
|
|||
[2013-08-13 16:54:12 NZST] read: git ["--git-dir=/home/walter/Photos/.git","--work-tree=/home/walter/Photos","log","refs/heads/git-annex..11a0c19d7c79f3e574b81295782ab2820caea232","--oneline","-n1"]
|
||||
[2013-08-13 16:54:12 NZST] read: git ["--git-dir=/home/walter/Photos/.git","--work-tree=/home/walter/Photos","log","refs/heads/git-annex..cad75ea77d513a24006ee0b56ff0aad12b7aa805","--oneline","-n1"]
|
||||
"""]]
|
||||
|
||||
[[done]]
|
||||
|
|
|
@ -13,3 +13,5 @@ Create a shared repository (core.sharedrepository = group), let a different user
|
|||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
Debian's 4.20131106~bpo70+1
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -27,3 +27,5 @@ upgrade supported from repository versions: 0 1 2 4
|
|||
### Please provide any additional information below.
|
||||
|
||||
The only workaround I found is to use a glob for the filepath which only works for the first space: *include='pictures/dir\*'*.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -29,3 +29,5 @@ git-annex: copy: 1 failed
|
|||
workaround: `cd .git/annex/; mv transfer transfer.old` on the other side.
|
||||
|
||||
-- [[anarcat]]
|
||||
|
||||
[[moreinfo]]
|
||||
|
|
|
@ -96,3 +96,5 @@ as usual. Then run `git annex initremote type=git name=foo
|
|||
location=$url`.
|
||||
|
||||
[[!meta title="webapp shows transfer from 'unknown' when no remote is configured for a system that is downloading files"]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -46,3 +46,5 @@ it assumes they never trap SIGINT on their own.
|
|||
Which is why the current behavior of not blocking SIGINT was chosen,
|
||||
as a less bad alternative. Still, I'd like to find a better one.
|
||||
--[[Joey]]
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -52,3 +52,6 @@ Optionally, editing the meta-data should change the times in all annexes.
|
|||
|
||||
>>>>>>>>> softbox sounds _really_ nice. File systems need to preserve mtimes. Oviously, it would be nice if git-annex exposed this to the upper layer instead of relying on this FUSE implementation, or the next, or the other totally cool thing around the corner to implement it again and again.
|
||||
>>>>>>>>> I talked to the author of metastore; he is aware that the format is merge-unfriendly but never needed merges for himself. He is aware that this is not ideal for something like git. He does not have the time to implement a text storage instead of binary and I lack the skills to do it. If metastore is used, all it would need to do is introduce a new version of the store (it's versioned, apparently) and save metadata in text, one file per line. xattr would need to be ASCII-armoured, the rest could be plain text. I still think storing this directly in git-annex would make the most sense. Introducing a metadata storage file per storage object in .git/annex and using the object file's name as index is impossible because several softlinks might point to one object so it would need to be done per-softlink :/ -- RichiH
|
||||
|
||||
> I think this is fixed by metamonger or something? Anyway, it's out of
|
||||
> scope for git-annex, so [[done]] --[[Joey]]
|
||||
|
|
|
@ -5,3 +5,5 @@ does not find git-annex there.
|
|||
I think that there is documentation or at least past advice of symlinking
|
||||
this way to install it into PATH. So need to do something about this.
|
||||
Perhaps have an installation script? --[[Joey]]
|
||||
|
||||
[[done]]
|
||||
|
|
|
@ -17,3 +17,4 @@ make: *** [Touch.hs] Error 1
|
|||
I dug around the OSX documentation and fcntl.h header file and it seems that UTIME_OMIT, UTIME_NOW, AT_FDCWD and AT_SYMLINK_NOFOLLOW aren't defined (at least on OSX). I suspect the BSD's in general will have problems compiling git-annex.
|
||||
|
||||
[[!meta title="annexed symlink mtime matching code is disabled on non-linux systems; needs testing"]]
|
||||
[[!tag confirmed]]
|
||||
|
|
5
doc/bugs/unconfirmed.mdwn
Normal file
5
doc/bugs/unconfirmed.mdwn
Normal file
|
@ -0,0 +1,5 @@
|
|||
These bug reports have not yet been confirmed by the git-annex developers
|
||||
to be actually bugs in git-annex, rather than some other problem.
|
||||
|
||||
[[!inline pages="./* and link(./unconfirmed) and !link(./done) and !*/Discussion" sort=mtime show=10
|
||||
archive=yes]]
|
|
@ -26,3 +26,5 @@ i see two ways to enhance the situation:
|
|||
|
||||
* silence the "not found" error when the file is found in another location
|
||||
* a way to rename the files in the remote (i guess the aaa/bbb part can be derived from the file name; in that case, that could even be done w/o network interaction).
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -39,3 +39,8 @@ Note that I had to close the chromium tab that was displaying the actual webapp
|
|||
Note also that things calmed down since git-annex started transfering larger files - the webapp only takes 75% of the CPU now. ;) And chromium is negligible. But there clearly seems to be a degenerate case where a lot of small files get transfered that seem to freakout the web UI. -- [[anarcat]]
|
||||
|
||||
Oh, and just copying the files using `git annex copy --to backup` doesn't use 100% of the CPU.
|
||||
|
||||
> Anarcat also files a bug about the assistant using too much CPU, and that
|
||||
> turned out to be due to a bug in the fsck scheduler that made it spin.
|
||||
> I suspect this is the same bug, which is fixed now, so closing. [[done]]
|
||||
> --[[Joey]]
|
||||
|
|
|
@ -42,3 +42,5 @@ What version of git-annex are you using? On what operating system?
|
|||
Linux ... 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
|
||||
|
||||
Please provide any additional information below.
|
||||
|
||||
[[!tag confirmed]]
|
||||
|
|
|
@ -28,3 +28,6 @@ Windows 7 64 bit
|
|||
"""]]
|
||||
|
||||
[[!meta title="windows installer fails unless run as admin user"]]
|
||||
|
||||
> [[dup|done]] of
|
||||
> [[git-annex_does_not_install_on_windows_without_admin_rights]] --[[Joey]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue