<div dir="ltr"><div>Hello Fabio and Jakob, thanks for responding.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Sorry to hear you're having issues pushing to remote from your image.<br>
I have no idea what's going on, maybe renew your access token and try<br>
again? What OS/VM/image are you using?<span class="gmail-im"><br></span></div></blockquote><div><br></div><div>I'm running macOS 10.15.1. Here's my about info:</div><div>Squeak5.3<br>latest update: #19448<br>Current Change Set: HomeProject<br>Image format 68021 (64 bit)<br><br>Virtual Machine<br>---------------<br>/Applications/Squeak5.3-19431-64bit.app/Contents/MacOS/Squeak<br>Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715] 64 bit<br>Mac OS X built on Mar  3 2020 08:28:30 GMT Compiler: 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)<br>platform sources revision VM: 202003021730 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a> Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a><br>CoInterpreter VMMaker.oscog-nice.2715 uuid: 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020<br>StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry for the issue. Can you please press the Debug button in the<br>
dialog and tell me some more about the `response` variable you should<br>
see in the top context? For example what is the `response code` (401<br>
or 403) or the `response content`? </blockquote><div><br></div><div>The response code is `401 Authorization Required`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Could you please inspect whether the `response request` actually<br>
contains authentication headers? I have seen in the past that<br>
sometimes the WebClient does not send them when it should.</div></blockquote><div><br></div><div>It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''<a href="http://github.com">github.com</a>'')'`</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>If you restart the context in the debugger (should be either<br>
GitSmartHTTPProtocol>>#discoverReferencesForService: or<br>
GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to<br>
repeat the request, does the same error occur again or does it work on<br>
second try?</div></blockquote><div><br></div><div>Ok, so this seems to have worked! Restarting #invokeReceivePackWithRefs:andPack:deleting: and proceeding seems to have done the trick! I have no idea why, of course. Any hints there? Either way, thanks for the tip. I've checked github and my latest changes are pushed.</div><div>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>when you added your<br>
project, the GitBrowser asked you for a local directory. Although<br>
Squot does not touch the working copy on the filesystem (the files<br>
that end up on GitHub), it does keep the repository metadata<br>
(everything in .git) in sync. So that means you can just push from<br>
your terminal from your filesystem repository.</div></blockquote><div><br></div><div>I was hoping a local file copy was there (as it has been when I manually pushed Monticello stuff in the past), but when I went snooping I didn't see anything. Also one thing I've noticed that might be of interest here is that when I first cloned my existing repo, and it asked for a folder to clone into, it seems to have put the .git file directly in that folder. This happens to be a folder that I keep all of my working images in, so that's not a good place. But the reason I did it that way is because I expected the normal git behavior: when you clone a repository on the command line in git, it *creates a new directory with the repo name* and puts the .git and other files inside of that directory. So when I selected ~/my_images/ or whatever as the clone directory with Squot, my git experience led me to believe I would find something at ~/my_images/<repo-name>/.git but instead it's just at ~/my_images/.git</div><div><br></div><div>One last semi offtopic thing: is the Squeak community aware that Github will be deprecating password based authentication come November?</div><div><br></div><div>Anyway the debugging/solutions you've all provided here seem to have done the trick for now  -- thanks!<br></div><div><br></div><div> <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 11, 2020 at 4:02 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br>
<br>
Sorry for the issue. Can you please press the Debug button in the<br>
dialog and tell me some more about the `response` variable you should<br>
see in the top context? For example what is the `response code` (401<br>
or 403) or the `response content`? I would ask for the whole object,<br>
but it also contains the request and that should contain your<br>
credentials in the headers, which I don't want to see obviously. :-)<br>
Could you please inspect whether the `response request` actually<br>
contains authentication headers? I have seen in the past that<br>
sometimes the WebClient does not send them when it should.<br>
<br>
If you restart the context in the debugger (should be either<br>
GitSmartHTTPProtocol>>#discoverReferencesForService: or<br>
GitSmartHTTPProtocol>>#invokeReceivePackWithRefs:andPack:deleting:) to<br>
repeat the request, does the same error occur again or does it work on<br>
second try? If the WebClient shows further problems, you can also try<br>
to restart the topmost SquitBrowser context that you find on the<br>
stack.<br>
<br>
About backing out: like Fabio said, the Git history is all on your<br>
disk and you can still pull/push/... with the Git command line. To see<br>
the files, you just have to checkout a commit (or reset --hard to see<br>
the latest files on the branch). Then you will find everything in<br>
filetree format (or Tonel if you configured it so). A converter exists<br>
for Monticello->Squot (see<br>
<a href="https://github.com/hpi-swa/Squot/#converting-monticello-history" rel="noreferrer" target="_blank">https://github.com/hpi-swa/Squot/#converting-monticello-history</a>), but<br>
not for the other way around, since Squot repositories are just<br>
metadata-less filetree repositories. If someone really wants to build<br>
a converter for the other direction, they could probably learn from<br>
the existing converter and turn the read/write logic around. However,<br>
I would rather like to find and fix your push issue.<br>
<br>
Kind regards,<br>
Jakob<br>
<br>
Am Sa., 11. Juli 2020 um 08:43 Uhr schrieb Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>>:<br>
><br>
> Hi Eric:<br>
><br>
> On Sat, Jul 11, 2020 at 2:07 AM Eric Gade <<a href="mailto:eric.gade@gmail.com" target="_blank">eric.gade@gmail.com</a>> wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > I have a project I've been working on using Squot and the new Git tools and pushing to a repository I have on Github. The repository is private but works with my username and password. I have been successfully pushing commits to it for a couple of weeks from the same image. This includes commits that I made yesterday. But today, suddenly, I am no longer able to push to my remote. Instead, I get the error in the attached image.<br>
> ><br>
><br>
> Sorry to hear you're having issues pushing to remote from your image.<br>
> I have no idea what's going on, maybe renew your access token and try<br>
> again? What OS/VM/image are you using?<br>
><br>
> > Note that I have not changed any Github settings or anything like that. So I'm not sure what has changed or what's going on. Any ideas?  Is anyone else having this issue? If I wish to find a way to "back out" of using Squot, is there some way to convert everything to Monticello (filetree) and just push it manually from my terminal?<br>
> ><br>
><br>
> No need to back out of using Squot just yet: when you added your<br>
> project, the GitBrowser asked you for a local directory. Although<br>
> Squot does not touch the working copy on the filesystem (the files<br>
> that end up on GitHub), it does keep the repository metadata<br>
> (everything in .git) in sync. So that means you can just push from<br>
> your terminal from your filesystem repository. This use case is one of<br>
> many reasons why Squot asks for a local directory.<br>
><br>
> Hope this helps,<br>
> Fabio<br>
><br>
> > --<br>
> > Eric<br>
> ><br>
><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div>