Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
b7835701c8
8 changed files with 148 additions and 0 deletions
|
|
@ -0,0 +1,30 @@
|
|||
### Please describe the problem.
|
||||
|
||||
In a repository with submodules, if I want to initialise git-annex on all submodules, I expect that `git submodule foreach git annex init` should work. Other `git-annex` commands seem to work with the `submodule foreach` command just fine.
|
||||
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
1. Clone a repository with submodules (recursively): `git clone --recursive <remote>`
|
||||
2. Initialise the main repository's annex: `git annex init`
|
||||
3. Try to initialise git-annex in all submodules: `git submodule foreach git annex init`
|
||||
|
||||
This produces the following error:
|
||||
```
|
||||
git-annex: git: createProcess: runInteractiveProcess: chdir: inappropriate type (Not a directory)
|
||||
fatal: run_command returned non-zero status for scripts
|
||||
.
|
||||
```
|
||||
|
||||
As a workaround, manually changing directory into each submodule and running `git annex init` works, but there are cases where having a general script that can iterate submodules is convenient.
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
- git-annex version: 8.20201007-gcf33be21ac
|
||||
- OS: Arch Linux
|
||||
|
||||
|
||||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
|
||||
I use it regularly with great success :)
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
[[!comment format=mdwn
|
||||
username="kyle"
|
||||
avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
|
||||
subject="comment 1"
|
||||
date="2020-10-20T15:59:26Z"
|
||||
content="""
|
||||
I can trigger this issue on my end too (tried with
|
||||
7.20190503-g4da50456a and 8.20201008-gad86a25c5). In case it's
|
||||
helpful, here is a minimal reproducer:
|
||||
|
||||
[[!format sh \"\"\"
|
||||
set -ue
|
||||
|
||||
cd \"$(mktemp -d \"${TMPDIR:-/tmp}\"/gx-XXXXXXX)\"
|
||||
|
||||
git annex version
|
||||
pwd
|
||||
|
||||
git init src
|
||||
(
|
||||
cd src
|
||||
git init sub
|
||||
git -C sub annex init
|
||||
git -C sub commit --allow-empty -m sub-c0
|
||||
git submodule add ./sub
|
||||
git commit -m sub
|
||||
)
|
||||
|
||||
git clone --recursive src dest
|
||||
(
|
||||
cd dest
|
||||
git annex init
|
||||
git submodule foreach 'git annex init'
|
||||
)
|
||||
\"\"\"]]
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
|
||||
avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
|
||||
subject="comment 3"
|
||||
date="2020-10-21T07:51:37Z"
|
||||
content="""
|
||||
Great! Thanks for checking and for the minimal reproducible example!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Probably it is more of a todo than a bug.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
This is a use-case where I am trying to establish a special remote to be shared by multiple unrelated repositories.
|
||||
|
||||
So I had original repo1 in which I
|
||||
|
||||
- created an external special remote with chunking, it got UUID1
|
||||
- uploaded some data (all got chunked)
|
||||
|
||||
created repo2 in which I
|
||||
|
||||
- initialized special remote with identical settings and provided `uuid=UUID1`
|
||||
- decided to test if annex would be able to get a key from the shared special remote
|
||||
|
||||
but `annex fsck --key KEY --from remote --fast`, since it doesn't have an exact chunking list, just provides special remote backend with original full key only, which is obviously not found, and it reports failure. But I wondered -- couldn't `git-annex` just use chunking size and "mint" possible chunked-keys to test on the special remote since it has all the information? After all chunk keys AFAIK are deterministically minted and pretty much are just "augmented" original key with `-S<chunksize>-C<chunkindex>` added to the key.
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
8.20200908+git175-g95d02d6e2-1~ndall+1
|
||||
|
||||
[[!meta author=yoh]]
|
||||
[[!tag projects/dandi]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 5"
|
||||
date="2020-10-20T12:29:19Z"
|
||||
content="""
|
||||
It isn't exactly \"how git-annex installed\" but rather, what else is installed besides git-annex. Recommended way to install datalad on OSX and Windows is via [anaconda](https://www.anaconda.com/) or [miniconda](https://docs.conda.io/en/latest/miniconda.html) from conda-forge channel. See So it places itself into `PATH` ahead of the rest, and it is the one which comes ATM with outdated `cp`.
|
||||
[It seems](https://github.com/conda-forge/coreutils-feedstock/issues/8) that `cp` might come also with `git` package there, and I have initiated (but didn't progress) [effort](https://github.com/conda-forge/coreutils-feedstock/issues/8) to build newer coreutils for Windows for conda-forge. (there is also some other m2sys channel with somewhat newer coreutils build, but mixing channels that much is begging for more of other issues). So, eventually, I hope that there would be updated `cp` available by default with `datalad` installation, but the point is that unless git-annex uses the specific `cp` it knows about, it could be some other `cp` in its way.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 6"
|
||||
date="2020-10-20T12:33:29Z"
|
||||
content="""
|
||||
> --reflink seems unlikely to do anything useful on windows even if the option is supported, so it could just be defaulted to not supported on windows.
|
||||
|
||||
yeap, sounds good to me ATM.
|
||||
|
||||
> -a/-p/--preserve-timestamps are more important and also probed at build time.
|
||||
|
||||
If I read NEWS correctly, it was added in 4.1.10, so old enough (was I even born then?) ;)
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 7"
|
||||
date="2020-10-20T16:39:15Z"
|
||||
content="""
|
||||
oh, just now realized that `git-annex.exe` is in **exactly** the same `C:\Program Files (x86)\Git\usr\bin` as `cp` etc -- so specifying specific path of where `git-annex.exe` installed (I bet the process would know which dir it is coming from) to `cp` and all those tools for a windows build could potentially make those installations more robust overall.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
[[!comment format=mdwn
|
||||
username="ericm"
|
||||
avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
|
||||
subject="comment 3"
|
||||
date="2020-10-20T13:45:09Z"
|
||||
content="""
|
||||
This worked for me:
|
||||
|
||||
git -c annex.largefiles=largerthan=200mb -c annex.addsmallfiles=false annex add --backend=WORM .
|
||||
|
||||
Then this adds the remaining files:
|
||||
|
||||
git annex add .
|
||||
|
||||
Thanks for the help!
|
||||
"""]]
|
||||
Loading…
Add table
Reference in a new issue