Trouble pushing a branch up to github
I have developed a new version of chordcalc with capo functionality. I hav used gitui and shellista to maintian a local ghit reposity for the development. The new verison is in a separate branch.
</Documents/chordcalc/chordCalc >git branch * devel-capo 7aac5134396f573be52c5494a9849735eb301130 master dd25f66bcc16976f12d787167d356c30081c590c </Documents/chordcalc/chordCalc >
When I tried to use gitui to push the new branch up to github, I get a OSError (Error No. 1) "operation not permitted" When I try to use shelista and enter the command :
git push (after doing a commit),
Error: <urlopen error [Errno 41] Protocol wrong type for socket>
Thoughts? The new branch already exists on github.
wradcliffe last edited by
It looks like some kind of permissions problem. If you just want to get it done, you could login to github via your browser and "edit" each file (the pencil icon) and copy paste the new code. You will have to use filenav or some other method to open the pui file in the editor but it should be fine and will validate that your login is working.
When you say the new branch exists on github, did you A) create a local branch and create a github branch separately? Or, B) did you create the branch on github, then pull it into pythonista/gitui?
If you did A, I think that creates a conflict that the primative git client cannot deal with. If B... not sure what that wouldn't have worked. If you can post a full traceback from gitui, that could be helpful. Are you using the latest gitui (which had some fixes for a few OSErrors, mostly for missing files i think)
The git clients right now on pythonista don't deal with conflicts well, or, at all really.
The best way to handle this sort of thing is to clone into a new folder, switch/checkout the new branch, the use pythonista or stash to copy the modified files from your old repo into the new folder. Then, add/commit the changes and push again from the new folder.
- Its case A. I have back ed up everything up and may try:
git push origin :dev-capo
which supposedly will delete the remote branch
- Just how does one "capture" the traceback other than a screen capture? Needs to become a feature if there is no copy to clipboard now.
Also, can pythonista load a pretty-printed pyui file? Would make for easier reading on github.
Porcelain was attempting an os.fork() call. I believe that is a IOS no-no.
dgelessus last edited by
pyui files in non-compact format seem to work fine. At least Pythonista didn't mind a few pointless line breaks in between dictionary items, so I suppose real pretty-printing should not be an issue either.
What version of dulwich are you using?
Gitview/shellista were using a custom version, based on dulwich 0.9.8. In that older version, fork was not used.
If you had installed one direct from github more recently, they added a fork call at some point.
Also, not that most of the push syntax is not supported in the git commands on pythonista.
For instance, you cannot specify the remote branch to push to.
I did it the hard way. Copy Paste, but its all there. Thanks. Now I know more about git than I really care to know.
there are two verision of dulwich in my system, both 0.9.8. One is installed in ~/site-packages, one in ~/plugins. Not sure how each arrived, as I have stash, shellista and gitui installed.
Ok, looked at this for a while tonight.
First, go ahead and run the install_gitview.py script, and delete the dulwich version in plugins.
I think that must be a very old version, as the latest has no os.fork calls. Actually, I will soon update this to point to a new repo, which merges dulwich 0.9.9 into the transistor modifications.
Second, I was wrong, you can create local branches and push. But, you can only push if there has been a commit, you can't push a branch that is identical to an existing. This seems to be a bug in the way github works, but I'm not sure. As far as I can tell the request appears valid. So, the workaround is to simply do an extra commit after creating a branch. Gitview won't let you do this, but I will change that so it will just warn, but let you commit anyway.
Nope. Ran it and it still seems to try to fork. Here are the first two lines in the install_gitview.py file
#DULWICH_URL='https://github.com/jelmer/dulwich/archive/master.tar.gz#module_name=dulwich&module_path=dulwich-master/dulwich&move_to=site-packages' GITTLE_URL='https://github.com/jsbain/gittle/archive/master.tar.gz#module_name=gittle&module_path=gittle-*/gittle&move_to=site-packages' FUNKY_URL='https://github.com/FriendCode/funky/archive/master.tar.gz#module_name=funky&module_path=funky*/funky&move_to=site-packages&save_as=funky.tar.gz' DULWICH_URL='https://github.com/transistor1/dulwich/archive/master.tar.gz#module_name=dulwich&module_path=dulwich-master/dulwich&move_to=site-packages'
Which repo should it be? Will it overright if it exists?
SO I pulled down the test branch of gitview. Now, only some repos are readable. Like the gitview one. Mine gives the error:
Global _find_repo not defined, line 197 of gitui.py called at line 538.
If I first open up gitview.py in the editor, then switch repos, mine opens just fine. It's obviously an older version. No log button. Can I get the old working one from somewhere?
@OMZ Oh, for a way to cut and paste tracebacks.
Here's my nevermind moment and a good trick in future:
>>> import sys >>> sys.last_traceback <traceback object at 0xf0b07c> >>> import traceback >>> traceback.print_last() Traceback (most recent call last): File "/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/gitview/gitui.py", line 538, in <module> repo_path=r._find_repo(editorpath) File "/var/mobile/Containers/Data/Application/64CF6C5F-B7C9-41FE-BB56-FF7EED134330/Documents/gitview/gitui.py", line 197, in _find_repo return _find_repo(parent) NameError: global name '_find_repo' is not defined
Need to make this an action menu item!!!
yikes... master is currently the version to use. Use GitHubGet or one of the other git downloaders to recover, or try using the commandline git to switch to master again.
Can you paste a traceback that has the fork in it?
yikes, apparently some testing resulted in pushing an empty branch into master, along wth the entire history. I could have sworn older versions of dulwich didn't allow this.
Got the new old master. You need to patch the log view window size due to the new behaviour of 1.6 regarding default view sizes. Seems I can't find where that fix was posted. Starting to need an index of some sort on this thing.