-2

How to download all files of a GitHub project with wget?

All files should be downloaded in their raw form.

Already tried:

wget -P ~/ https://raw.githubusercontent.com/u/p/b/*
wget -P ~/ https://raw.githubusercontent.com/u/p/b/{*}
wget -P ~/ --accept-regex urlregex https://raw.githubusercontent.com/u/p/b/*
wget -P ~/ --recursive https://raw.githubusercontent.com/u/p/b/

This is opposed to wget -P ~/ https://raw.githubusercontent.com/u/p/b/{file1,file2...}

u=user,p=project,b=branch.

3 Answers3

3

This is one way:

wget -P ~/ https://github.com/u/p/a/master.zip
unzip ~/master.zip

This is another:

cd
wget https://github.com/u/p/a/master.zip
unzip master.zip

u=user, p=project, a=archive.

2

Short version: you can't.

Longer version 1: If you're trying to clone a git working directory, that directory needs to be under your $WEBROOT, so your web server can see and serve the files.

Longer version 2: If you're trying to clone a bare git repository, the files don't actually exist in raw form. They're entries on the projects object database.

Best idea:

git clone http://...
dafydd
  • 1,458
1

This worked for me on a repository although it requires a tool called json (similar to jq) and I don't recommend doing this over git clone.

#!/bin/bash

MY_REPO='/jessebutryn/wtfisbash'

GIT_API='https://api.github.com/repos'
GIT_URI='/contents'
CURL_OPTS=(
    -X
    GET
)

REPO_DIRS=($(curl "${CURL_OPTS[@]}" "${GIT_API}${MY_REPO}${GIT_URI}" \
    | json -a -c "type === 'dir'" name))
REPO_FILES=($(curl "${CURL_OPTS[@]}" "${GIT_API}${MY_REPO}${GIT_URI}" \
    | json -a -c "type === 'file'" download_url))

for dir in "${REPO_DIRS[@]}"; do
    REPO_FILES+=($(curl "${CURL_OPTS[@]}" "${GIT_API}${MY_REPO}${GIT_URI}/${dir}" \
        | json -a -c "type === 'file'" download_url))
done

for file in "${REPO_FILES[@]}"; do
    wget -P ./ "${file}"
done

I should also note this will only work for files up to one directory deep. If you have more directories than that I'm sure you can figure out how to dive into them with this -- but it's starting to give me a headache.

Kusalananda
  • 333,661
jesse_b
  • 37,005
  • @Vlastimil: They aren't reserved for anything. I know what I'm doing and they look cleaner. – jesse_b Feb 03 '18 at 10:12
  • 1
    Well, they aren't reserved as a matter of fact, but regarding style, you should always avoid using uppercase variable names. If you do this on daily basis, it's a bad habit, what more shall I say? – Vlastimil Burián Feb 03 '18 at 10:26
  • It's just a recommendation: https://unix.stackexchange.com/a/42849/126755 – Vlastimil Burián Feb 03 '18 at 10:28
  • I used to have that opinion too, but it really doesn't matter. Even if they did conflict with an environmental variable my script would take the value of the shell variable. I also also prefix my variables with something to ensure they don't clash and check env if I'm not sure. – jesse_b Feb 03 '18 at 10:29
  • -1 | Ok, we agree on one thing, that we disagree on the issue. I hoped you'd come to senses, but you seem to be stuck with your style. – Vlastimil Burián Feb 03 '18 at 10:31
  • Can you tell me what the problem would be if they did clash with environmental variables? I'll wait. – jesse_b Feb 03 '18 at 10:33
  • There is no problem other than the bad habit of your naming style, which I strongly disagree with. End of discussion, please. – Vlastimil Burián Feb 03 '18 at 10:35
  • "There is no problem" -@Vlastimil Thanks, all I needed to hear. – jesse_b Feb 03 '18 at 10:36