You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(fdm-werkstatt) adina@muninn in /tmp
❱ datalad clone osf://b37a8
install(error): /tmp/b37a8 (dataset) [Failed to clone from any candidate source URL. Encountered errors per each url were:
- osf://b37a8
CommandError: 'git -c diff.ignoreSubmodules=none clone --progress osf://b37a8 /tmp/b37a8' failed with exitcode 128 [err: 'Cloning into '/tmp/b37a8'...
100%|██████████| 143/143 [00:00<00:00, 377kbytes/s]
Downloading repository archive
100%|██████████| 51.1k/51.1k [00:00<00:00, 968kbytes/s]
Extracting repository archive
fatal: ambiguous argument 'refs/heads/master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: Command '['git', 'fast-export', '--import-marks=/tmp/b37a8/.git/osf/origin/osf.marks', '--export-marks=/tmp/b37a8/.git/osf/origin/osf.marks', '--refspec', 'refs/heads/*:refs/osf/origin/*', 'refs/heads/master', 'refs/heads/git-annex', 'refs/heads/main']' returned non-zero exit status 128.
fatal: stream ends early
fast-import: dumping crash report to /tmp/b37a8/.git/fast_import_crash_652406
fatal: error while running fast-import']]
The inability to clone from non-master is another. I can replicate that. I verified that it pushes something like main correctly. Somehow the problem depends on the default branch on the target system to be master. Need to dig deeper.
With datalad/datalad-osf#174, this is now a problem in datalad-next rather than a problem here and in datalad-next. I will transfer the issue. A fix is found.
mih
transferred this issue from datalad/datalad-osf
Jun 8, 2023
mih
added a commit
to mih/datalad-next
that referenced
this issue
Jun 8, 2023
Whenever a repo had a HEAD branch that differed from the configured
default branch in Git, the mirror repo would be on the configured
default. On push this configured default would become the configured
HEAD on the remote, and on clone this would fail to yield a
checkout, because the actual repo content might not even
have that branch.
A typical use case would be a repo with a `main` branch, but a system
that has `master` to be the configured default.
Closesdatalad#412
Maybe the
datalad-annex
git remote helper can be a useful replacement here, but the file names we are using in datalad-osf don't fit what it expects: http://docs.datalad.org/projects/next/en/latest/generated/datalad_next.gitremotes.datalad_annex.html#module-datalad_next.gitremotes.datalad_annexThe text was updated successfully, but these errors were encountered: