"git fetch" not working in Weblish
In the weblish console, I've cloned a git repository into my /projects folder. That required me to put my github username and personal access token to login, and I was successful with that.
However, with the repo active, I'm unable to "git fetch" successfully. Like the cloning step, I need to log in using my username and token, but after that, nothing happens. If I enter an incorrect token, I get an error message. But if I enter the correct token, it just fails silently anyway.
See below for excerpts from the terminal in Weblish:
root@localhost:~/projects#
git clone https://github.com/USER/REPO.git
Cloning into 'REPO'…
Username for 'https://github.com':USER
Password for 'https://USER@github.com':PERSONAL ACCESS TOKEN
remote: enumerating objects (etc…)
remote: counting objects (etc…)
etc…
Resolving deltas: 100% (etc…) done.
I successfully authenticated and got the repo cloned. But then…
root@localhost:~/projects#
cd REPO
root@localhost:~/projects/REPO#git branch -a
*main
remotes/origin/HEAD -> origin/main
remotes/origin/branch2
root@localhost:~/projects/REPO#git fetch -a
Username for 'https://github.com':USER
Password for 'https://USER@github.com':PERSONAL ACCESS TOKEN
root@localhost:~/projects/REPO#
root@localhost:~/projects/REPO#git branch -a
*main
remotes/origin/HEAD -> origin/main
remotes/origin/branch2
It just doesn't do anything. If I provide an invalid token I get:
root@localhost:~/projects/REPO#
git fetch -a
Username for 'https://github.com':USER
Password for 'https://USER@github.com':BAD PERSONAL ACCESS TOKEN
fatal: Authentication failed for 'https://github.com/USER/REPO.git/'
root@localhost:~/projects/REPO#
So it seems to be a problem with how I'm fetching or something. Can anyone offer guidance on this?
Thank you!
- edit: I get the same behavior with "git fetch", "git fetch -a", "git fetch origin branch", etc
2 Replies
✓ Best Answer
Hi @watrick, thanks for taking the time to respond. I found the verbose option very helpful to know something was at least happening.
As it turns out, according to this stack overflow answer, "fetch will not create local branches (which track remote branches) […] [git pull] will work only for your local branches which track remote branches".
So, I used what was recommended in the last portion of the answer:
for remote in `git branch -r`; do git branch --track ${remote#origin/} $remote; done
It seems (for some still-unknown reason) I had to manually "track" the branches locally in order to have access to them. At this point, git branch -a will display local copies of the previously only-remote branches. And I can now pull down changes coming from remotes as well.
I also found git checkout -b local_branch_name origin/remote_branch_name, which seems intuitive and simpler, in the answers, but that was after I used the above to solve my prolem. So unsure if it works for this use case.
Thanks again for looking into this. I hope you find this answer interesting at least.
watrick
Linode Staff
I've yet to encounter a situation like this, though I looked at the git fetch --help menu and found a couple of arguments of interest. I think they will provide a workaround or give you more useful information:
Possible workarounds:
--allFetch all remotes.
This argument can ensure you're pulling in what you need, though this can be heavy handed.
-p, --pruneBefore fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option.
This is the first I'm seeing this option for git, though I'm recommending it after needing to use the prune option with Docker somewhat often. If it's as similar as I think it is, it'll clean up things to make sure the next attempt is cleaner.
Get more info:
-v, --verboseBe verbose.
As the name suggests, it'll output more information on your screen to help provide more details. This should help with any silent failures no longer being silent. It won't make it not fail, though.
--progressProgress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
Similar to the verbose option, this will provide more information as it's happening. Using Lish can make scroll back difficult, though though there is a keyboard option to do this. Using the progress option could help watching the issues as they occur so that you can start investigating a fix while the git command completes.