Merge branch 'master' of ssh://git-annex.branchable.com into master
This commit is contained in:
Joey Hess
commit
3c6cfacb19
8 changed files with 121 additions and 1 deletions
|
|
@ -0,0 +1,43 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Ref: Original issue and finding [report against datalad](https://github.com/datalad/datalad/issues/5015#issuecomment-709436065).
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
Windows 8.20200815-g335aae266 (I see now that I might benefit from update, but I found no related issue so likely it is something new)
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
|
||||
{920}[Level 5] CommandError: '"git" "annex" "add" "-c" "annex.dotfiles=true" "-c" "annex.retry=3" "--json" "--json-error-messages" "--debug" "--" "file.dat"' failed with exitcode 1 under C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_q4wxn05d [out: '{"command":"add","success":false,"error-messages":[" file.dat failed to link to annex"],"file":"file.dat"}'] [err: '[2020-10-15 11:57:07.4657537] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.dotfiles=true","-c","annex.retry=3","show-ref","git-annex"]
|
||||
| [2020-10-15 11:57:07.4813787] process done ExitSuccess
|
||||
| [2020-10-15 11:57:07.4813787] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.dotfiles=true","-c","annex.retry=3","show-ref","--hash","refs/heads/git-annex"]
|
||||
...
|
||||
| [2020-10-15 11:57:07.6376287] call: cp ["--reflink=auto","-a","file.dat",".git\\annex\\objects\\6f0\\fbd\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat"]
|
||||
| "cp": unrecognized option `--reflink=auto'
|
||||
| Try `"cp" --help' for more information.
|
||||
| [2020-10-15 11:57:07.6532537] process done ExitFailure 1
|
||||
|
||||
C:\tmp>cp --help | grep ref
|
||||
-d same as --no-dereference --preserve=link
|
||||
-L, --dereference always follow symbolic links
|
||||
-P, --no-dereference never follow symbolic links
|
||||
|
||||
C:\tmp>cp --version
|
||||
cp (GNU coreutils) 5.97
|
||||
Copyright (C) 2006 Free Software Foundation, Inc.
|
||||
This is free software. You may redistribute copies of it under the terms of
|
||||
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
|
||||
There is NO WARRANTY, to the extent permitted by law.
|
||||
|
||||
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
|
||||
"""]]
|
||||
|
||||
if I parsed NEWS.gz correctly, that option was added in `* Noteworthy changes in release 8.0 (2009-10-06) [beta]` . So I wonder if `git-annex` could sense for version of `cp` or presence of `--reflink` option and not use it if `cp` is too old?
|
||||
|
||||
Meanwhile I will see if there is some sensible way to get more uptodate coreutils (or `cp`) at least within conda env
|
||||
|
||||
[[!meta author=yoh]]
|
||||
[[!tag projects/datalad]]
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 1"
|
||||
date="2020-10-16T01:29:22Z"
|
||||
content="""
|
||||
a mental note... building git-annex in a windows vm ATM, and saw
|
||||
|
||||
```
|
||||
> stack ghc --no-haddock --package nsis Build/NullSoftInstaller.hs
|
||||
...
|
||||
[36 of 36] Compiling StackSetupShim ( C:\\sr\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\\tmp\git-annex\.stack-work\dist\
|
||||
29cc6475\setup\StackSetupShim.o )
|
||||
Linking C:\\tmp\\git-annex\\.stack-work\\dist\\29cc6475\\setup\\setup.exe ...
|
||||
checking UPGRADE_LOCATION... http://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe
|
||||
checking git... yes
|
||||
checking git version... 2.23.0.windows.1
|
||||
checking cp -a... yes
|
||||
checking cp -p... yes
|
||||
checking cp --preserve=timestamps... yes
|
||||
checking cp --reflink=auto... yes
|
||||
...
|
||||
checking ssh connection caching... no
|
||||
Configuring git-annex-8.20201007...
|
||||
```
|
||||
|
||||
so either the check is wrong or there are multiple `cp` around (may be some came with `stack`?) ... I found total over 10 different cp.exe on drive (didn't check yet how many in PATH). But I just wonder, if check is done at build time, but `cp` is not distributed along, the check should be done at run time instead.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 2"
|
||||
date="2020-10-16T01:50:39Z"
|
||||
content="""
|
||||
in datalad we took an approach that \"if bundled git-annex is used, use by default git which comes with it\". If assumption here for Windows is that \"cp which comes with git should be used\", then git-annex needs to use a specific PATH to use that one, and not some other which might be found in the PATH. The situation is a bit messy though since `git.exe` is at `/c/Program Files (x86)/Git/cmd/git.exe` (pasting from mingw'ed bash) while `cp` is under `/c/Program Files (x86)/Git/usr/bin/cp.exe` so not exactly the same directory, but I guess consistent for all Windows'es.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="building the standalone distribution on CentOS"
|
||||
date="2020-10-16T14:58:42Z"
|
||||
content="""
|
||||
\"This build process is done on a Debian system, and it needs to use dpkg to examine the host system\" -- would it be hard to make this work on CentOS? (For building the standalone tarball as part of building the [conda-forge package](https://github.com/conda-forge/git-annex-feedstock/), where the build process uses [this docker image](https://github.com/conda-forge/docker-images/blob/master/linux-anvil-comp7/Dockerfile).)
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
[[!comment format=mdwn
|
||||
username="fbaca1610@41d03d827c5fd52d594eef456b6196c057c0944f"
|
||||
nickname="fbaca1610"
|
||||
avatar="http://cdn.libravatar.org/avatar/43f0d5bb6f1b878853d43f69600310cd"
|
||||
subject="dropunused and copies"
|
||||
date="2020-10-15T10:19:16Z"
|
||||
content="""
|
||||
Hey there, love git annex!
|
||||
|
||||
I have a (silly?) question: `git annex dropunused` tells me that there are not enough copies. I agree it is a good thing or at least might be in some cases.
|
||||
|
||||
The problem is this: I have synced and used `git annex copy --to` for all my repositories and still I have unused files that `dropunused` will not delete, since it finds no copies.
|
||||
|
||||
Am I doing something wrong here? Why are these (now) unused files not copied and therefore okay to delete locally?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Lukey"
|
||||
avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
|
||||
subject="comment 2"
|
||||
date="2020-10-15T14:46:33Z"
|
||||
content="""
|
||||
`git annex sync/copy/move/etc.` don't operate on old/unused files by default. You have to use the `--all` option to operate on every file (even old/unused ones) or the `--unused` option to operate only on files found by `git annex unused`.
|
||||
"""]]
|
||||
|
|
@ -6,7 +6,7 @@ while `git add` adds files to git.
|
|||
Let's suppose you're developing a video game, written in C. You have
|
||||
source code, and some large game assets. You want to ensure the source
|
||||
code is stored in git -- that's what git's for! And you want to store
|
||||
the game assets in the git annex -- to avod bloating your git repos with
|
||||
the game assets in the git annex -- to avoid bloating your git repos with
|
||||
possibly enormous files, but still version control them.
|
||||
|
||||
You could take care to use `git annex add` after changes to the assets,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="copying directly from directory special remote to the cloud"
|
||||
date="2020-10-18T21:00:58Z"
|
||||
content="""
|
||||
One more use case: running git-annex inside a VirtualBox VM (Linux guest on Windows host), with the repo inside the VM, operating on files on the host through [shared folders](https://help.ubuntu.com/community/VirtualBox/SharedFolders). Shared folder is too large to copy inside the VM. With the recent addition of [[importing from directory special remote without downloading|https://git-annex.branchable.com/todo/importing_from_special_remote_without_downloading/]] (thanks @joeyh for implementing that!), can import the files into the repo, bypassing [[issues with VirtualBox shared folder filesystem|bugs/removeLink_failed_when_initializing_a_repo_in_a_VirtualBox_shared_folder]]. But can't upload the files to a cloud special remote, without first [[`git-annex-get`|git-annex-get]]ting them into the VM, and I unfortunately don't have space for two local copies of each file. So a direct transfer from a directory special remote to a cloud special remote would help a lot.
|
||||
|
||||
The alternative, of course, is to run git-annex directly on Windows, but I've run into speed issues with that, and using WSL means losing ability to run VirtualBox, so running git-annex from a guest VM and operating on host files through the shared folder filesystem -- broken as that is -- seems like the best option right now.
|
||||
"""]]
|
||||
Loading…
Add table
Reference in a new issue