In my experience, this unhelpful error is caused by GitHub rejecting the push, which happens if your local branch is not a descendent of Github's version... meaning if you make any changes directly on GitHub (ReadMe.md is always my problem), you need to remember to pull those changes back to your local repo before making any other commits.

With latest stash dev branch, the git merge command should let you fix this problem.

First, make whatever commits you need to make locally. A few of the later steps might not work with any uncommitted local changes. Here's a poor man's git stash that works in the current stash.

git branch tempbranch # creates tempbranch pointing at current HEAD
git reset tempbranch # HEAD now points to tempbranch.. no files have been changed
git add * # or whatever files you want to keep local mods
git commit # you are committing changes to tempbranch
git checkout devel-json #checkout clean copy of devel-json

(I assume here you're working on devel-json)

Next, let's just verify you have origin setup:

git remote

Verify that origin is present, and points to the right repo. If not, you can use

git remote origin https://github.com/polymerchm/chorcalc.git

to fix that. If you have used a semi-recent version of stash or gitui, to clone originally, origin should already be set up.

Next, let's fetch github's copy of the repo.

git fetch origin

This will fetch the latest on github. it will update the files in .git/refs/remotes/origin, but won't touch your working copy. You can use git branch -r to list the sha's of the remote repo branches.

Now, let's try to merge your current branch into the github version:

git merge origin/devel-json

The merge command basically finds a common ancestor between your branch, and the github branch, then does a 3 way diff. In many cases, it is unambiguous how to merge, and these changes are made automatically... you can probably just skip to where you commit and push. But, if both your branch and github changed the same file, then a similar process happens, now at the line level. Again, we try to merge automatically within a file, unless both the remote and local copies tried to change the same line. In that case, we have a conflict, and the file will be updated with conflict markers.

In case of a conflict, you'll have to manually edit the files to resolve conflicts (or use reset to force "mine" or "theirs" ... see below). If you manually resolve, search for <<<<< markers, and decide what to do for each conflict. If you make any changes to resolve conflicts, or if you edit any of the automatic merges, be sure to stage those changes with git add.

After the merge command, you can review the staged changes using git diff, to see the changes pending, and confirm the merge did what you want. gitui's diff capability is perhaps a little easier to use in that regard if there are many changes.

If you decide you don't like how a file was merged, you can reset it back to some previous commit:

git reset --mixed

will set the entire staging area back to match the last commit in your local branch. You could also just reset individual files

git reset --mixed somefile

If you want to force the merge to use "theirs" for an entire file, you'd specify the remote/branch as follows:

git reset --mixed origin/devel-json somefile

The --mixed option says to update the index (i.e. the staging area) but it won't update files in the working folder. If you want to be able to test the merged code before committing, you could use the --hard option instead, which also updates the files in the working directory ... but beware this will nuke any local unstaged changes.

Once you are satisfied with what's in the staging area, git commit will generate a commit that lists your devel-json branch as well as the github copy of devel-json as parents. The new commit is therefore a descendent of the github copy, and push should now be accepted.

If for some reason you started a merge, but change your mind, use git reset --merge which will remove the .git/MERGE_HEAD and .git/MERGE_MSG files, which tell the commit command that a merge is in progress.

Finally:

git push

should now work. It may be obvious, but be sure your network connection is active before pushing.

You won't be able to push until you can do a fetch, and then merge with the fetched remote.
(I just noticed that I misspelled the repo in the git remote origin command...so if you were copying/pasting that directly, that might be part of the issue.. use git remote to check that origin points to the right github address... i think i missed the d in chor__d__calc before)

I will try playing around with this tonight to see if i can reproduce the problem, or at least see if i can modify the broken pipe message to give something more useful.

Actually, can you try:cat .git/refs/remotes/origin/devel-json

If that is not set to 15047109c9d7a65ad8d433caa3d38d007be7ba1f (the current copy on github) that explains the pushing problem at least, since your local copy of the remote branch is not up to date.

IIRC, in this state you might still be able to push to a new branch name, although I have also seen where this doesn't work.

In other words, clone to a clean location, checkout the branch you are working on, copy your updated files from the original working folder, then add/commit/push.

I'd like to get to the bottom of what is happening... if you're willing, can you (from the folder that won't let you push or fetch) try this, and send me the results (maybe open an issue on the stash repo and post results there):

git branch -r
git log -l10

This will list the current branch sha`s, as well as a log of the last 10 commits, which we can compare against github to see where things have gone wrong.

Maybe there was a typo in all the other goobledeegook, because now when I did git fetch origin, it worked. As did git push. and a second modification of the readme followed by a commit and a push worked. Thanks