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 2020-06-03 11:40:24 -04:00
commit 697ebba78f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 118 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_3_e8636243a3c98b11e54b6fa8617f9e32._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="the13thletter"
avatar="http://cdn.libravatar.org/avatar/596520d6cdaa0709ae4413665b10ec7c"
subject="comment 3"
date="2020-06-02T14:26:52Z"
content="""
OP here. Sorry for the radio silence.
> I think it's quite likely that most people consider files in dotdirs to be dotfiles, most of the time. (.git/index is clearly not a dotfile, .git/config probably is) **The exact semantics of it are vague enough** that it's probably better to not consider them when it comes to this bug report.
>
> [...]
>
> I'm also reluctant to start another behavior change in this area, there has been more than enough drama around dotfile handling recently.
>
> [...]
>
> It would also be possible for users to get back the current behavior if desired by configuring annex.dotfiles and annex.largefiles.
(Emphasis mine.) Given the points above, which I agree with (1) or accept (2 and 3), I'm perfectly fine with documenting the current behavior as correct and leaving it at that. My confusion stems from the fact that when I see `.foo/bar`, I say “no dotfile, because the file is actually named ‘bar’”, and git-annex says “dotfile, because the pathname expression begins with a dot” (or something like that) instead. Stating the exact rules git-annex uses to classify dotfiles as such, ideally alongside the documentation for `annex.dotfiles` and `annex.largefiles`, would avoid this confusion.
"""]]

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

@ -0,0 +1,72 @@
Hi!
I'm using git-annex version: 8.20200522-g01513da12.
A file is present in 3 special remotes (one S3 and two rsync ones). I fsck-ed all theses repositories, no problem found. Numcopies is set to 2.
Whenever I try do drop the file from one of these special remotes, I have an error message:
Unable to lock down 1 copy of file that is required to safely drop it.
(This could have happened because of a concurrent drop, or because a remote has too old a version of git-annex-shell installed.)
Rather than dropping this file, try using: git annex move
(Note that these git remotes have annex-ignore set: origin)
(Use --force to override this check, or adjust numcopies.)
failed
git-annex: drop: 1 failed
**Do you know why I can't delete this file safely?** I don't really want to move the file from repository_s3 to my computer before dropping it from my computer, but maybe it is the only way.
Some debug here:
git annex drop --from=repository_s3 file
[2020-06-01 09:28:36.30172183] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
[2020-06-01 09:28:36.302839128] process done ExitSuccess
[2020-06-01 09:28:36.302910826] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
[2020-06-01 09:28:36.304674603] process done ExitSuccess
[2020-06-01 09:28:36.304870633] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","myfile"]
[2020-06-01 09:28:36.308566414] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
[2020-06-01 09:28:36.310718234] process done ExitSuccess
[2020-06-01 09:28:36.310777259] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
[2020-06-01 09:28:36.312706322] process done ExitSuccess
[2020-06-01 09:28:36.313462825] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..b855e6a77dbef6378695d43aca723d6586a5033d","--pretty=%H","-n1"]
[2020-06-01 09:28:36.315478283] process done ExitSuccess
[2020-06-01 09:28:36.315547977] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..225048506b610815513008d42e9b5d58d8024512","--pretty=%H","-n1"]
[2020-06-01 09:28:36.317466181] process done ExitSuccess
[2020-06-01 09:28:36.317524901] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..c517aa9598e8e7cd61f7ee4b8742d2d1b23eb4f3","--pretty=%H","-n1"]
[2020-06-01 09:28:36.319278416] process done ExitSuccess
[2020-06-01 09:28:36.319344343] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..5fce52950d6bf949ab90c07c7886410214c0fb78","--pretty=%H","-n1"]
[2020-06-01 09:28:36.320947418] process done ExitSuccess
[2020-06-01 09:28:36.324812884] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
[2020-06-01 09:28:36.325182947] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
[2020-06-01 09:28:36.330066795] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
drop wasabi-s3 myfile [2020-06-01 09:28:36.340825449] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
[2020-06-01 09:28:37.176503667] process done ExitSuccess
(checking repository1...) [2020-06-01 09:28:37.177417745] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/repository1' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","repository1:/home/troissinges/annex/ec8/502/'GPGHMACSHA1--982dee55ea35e4a6b123a0824084224c0d9d1855/GPGHMACSHA1--982dee55ea35e4a6b123a0824084224c0d9d1855'"]
[2020-06-01 09:28:38.544912886] process done ExitSuccess
[2020-06-01 09:28:38.545311227] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
[2020-06-01 09:28:39.467364936] process done ExitSuccess
(checking repository2...) [2020-06-01 09:28:39.467946703] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/repository2' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","repository2:/home/troissinges/annex/ff1/3c2/'GPGHMACSHA1--4524287d59896f3257f7a5880d598bae2cccc3a9/GPGHMACSHA1--4524287d59896f3257f7a5880d598bae2cccc3a9'"]
[2020-06-01 09:28:41.165332387] process done ExitSuccess
(unsafe)
Unable to lock down 1 copy of file that is required to safely drop it.
(This could have happened because of a concurrent drop, or because a remote has too old a version of git-annex-shell installed.)
Rather than dropping this file, try using: git annex move
(Note that these git remotes have annex-ignore set: origin)
(Use --force to override this check, or adjust numcopies.)
failed
[2020-06-01 09:28:41.170070605] read: ssh ["-O","stop","-S","repository2","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
[2020-06-01 09:28:41.175742495] process done ExitSuccess
[2020-06-01 09:28:41.175982476] read: ssh ["-O","stop","-S","repository1","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
[2020-06-01 09:28:41.179991665] process done ExitSuccess
[2020-06-01 09:28:41.180410006] process done ExitSuccess
[2020-06-01 09:28:41.180589281] process done ExitSuccess
[2020-06-01 09:28:41.180985889] process done ExitSuccess
git-annex: drop: 1 failed

9
doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_4_07a190aa19006611739cccfc5aac5a6f._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
nickname="branchable"
avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
subject="comment 4"
date="2020-05-31T11:03:05Z"
content="""
Thanks. Yes, I have it set to `refuse` globally in `~/.gitconfig`. I definitely don't want to unset it since that could really screw up my working trees. Your idea of disabling localization (`LANG=C` or similar, I guess?) and checking for \"refusing to update checked out branch\" sounds reasonable, but I would prefer a way to just stop it even *trying* to update anything other than `synced/$BRANCH`.
"""]]

17
doc/forum/git_update-index_message_after_git-annex_get.mdwn Normal file
View file

@ -0,0 +1,17 @@
After running `git-annex get` in an unlocked (adjusted) v8 repo with git-annex 8.20200330, I see:
> git status will show some files to be modified, since content availability has changed and git-annex was unable to update
> the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git
> status display, you can run: git update-index -q --refresh <file>
And indeed, some of the files I just got show as new, others as modified.
Where can I find more information on what happened here?
How can I run the update-index command safely without listing hundreds of files? Can I just run it over the directories those files were copied to?
Would you consider adding an option to run the update-index automatically where needed?
UPDATE: I just notice that the assistant apparently deleted some files from the git repository. When I check the file path with `git log <file>` I see the initial addition (locked, on a different machine, not adjusted) and then a deletion of the symlink on the machine where I executed `git annex get`. This is rather terrifying!
The file is still in the filesystem. The last commit to the annex happened over 30m ago, the last log in daemon.log over 20m ago. The assistant will probably not add these files back? But even if it would. It is dangerous that a simple `git annex get` leads to delete commits.

27
doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn
View file

@ -1,28 +1 @@
A replacement for a web-browser's downloads menu that uses git-annex internally ([[`addurl`|tips/using the web as a special remote]] command for the download, and `drop` or `git rm` for the clean up) would be quite helpful:
say, when working on a topic, writing a paper or similar things, I usually have a Git repo with my text, all relevant data and processing code, and possibly other background information. It's nice to store the literature you needed at the same place where you work. (So that it is easy to catch up with what I was doing and thinking over when I left this work aside for a while, perhaps after cloning the repo from another location.)
When I find an interesting literature, I save the file to the directory with my work, and read it. Then I might return to it to re-read it. There might be references to this document from my work, so I'd like them to work as links (perhaps pointing at the local file, but also at the source URL for the case when my document is read by someone else not on my system).
I need to keep track of the source URLs for the documents I have saved which I read and use.
That's a task that fits well git-annex.
Note that doing the dull work of copying and pasting the URL and the downloading it and then opening it for reading is a pain to do every time I'm interested in a document I have found on the web. (Of course, I would need to fill out the bibliogrphic information for this document if I want to refer to it, but that can be done later. Initially, I wish I just don't lose the source URL of a document at the moment when I get interested in it and start reading.)
So, I could be assisted by a replacement of the "downloads" menu of, say, Firefox: whenever I want to open a file for viewing (like a PDF), it should ask me where to save it, and I'd choose the directory with my work, then it should register it with git-annex (so that the source URL is saved, and perhaps it should also write down the referring page's URL somewhere nearby automatically), download it, and open with a viewer for reading.
Then I'll have the interesting literature there when I'm offline; the source URLs would be saved, so that they can be put into the references. Also, if I distribute this work with Git, at another location git-annex can be used to easily get all the literature again.
(Hmmm... probably, the browser that this will be simplest for me to implement for is emacs-w3m; simply, some functions calling git-annex...)
> This seems fairly doable to implement since the git-annex [[design/assistant]]
> already has a webapp. So a javascript toolbar thing could be made that
> submits the current url (or maybe links dragged into it?) to the webapp
> for adding to the annex.
>
> The only wrinkle is that the webapp runs under a new url each time
> it starts, due to using a high port and embedding some auth token in the
> url. --[[Joey]]
[[!tag /design/assistant]]