There is no ongoing merge pending so git is supposed to show you,

fatal: There is no merge to abort (MERGE_HEAD missing).

Now if you want to go back to previous state (state before you merged), try

$ git branch
      Experimentation
    * master
      pod-attempt
$ git reset --hard HEAD~24 

24, cause OP wants to go ahead of 24 commits.

You are done!

I suggest to x-post that question to r/git.

What do you mean by "unsaved a file"? Was it perhaps opened in an editor, then git made some changes to that file and your editor didn't reload the file and thefore shows the difference of your opened (old) state to the merged (new) state as pending changes that have to be saved?

You should be able to git stash any important changes that you apply later, then git reset --hard HEAD~n where n should be replaced with the relative commits count that you want to go back (you should look up the status and log so that you don't go back to far). That should cancel any bugged merge or anything. Then you could try a merge from a clean slate.

For the future consider actual backups so that you can delete something completely and just clone it again, then apply manual changes (that you could have temporarily moved out of the dirty/bugged repo). Data not worth backing up should be considered data not worth having.

(two identical migration files, neither of which has the same unique number prefix as the branch that I merged from). I tried to abort. But then I got an error There is no merge to abort (MERGE_HEAD missing)

I have no clue what happened to you.

Then it said I was 122 commits ahead of origin, so I tried to reset back 122 commits, but that went way too far back.

Depending on how you did the merge - either fast-forward or by creating a specific merge commit - the commit count may not represent the actual number of commits you have to go back to. If it was for example through creating a specific merge commit going back just 1 commit will go back to right before the merge happened, including all 122 commits that came with the merge. It may always be benefitial to look at the branch view with git log --graph or some GUI client with a strong recommendation for ordering commits after their commit date.

But I want to rename it, and get the "completed" project a new repo with the right name, and without all the back work for anyone to go poking around in. (is that how it's usually done, to start a new repo, or do dev's just rebase their projects back to the beginning?)

Uhh.. neither. I don't really get what you want to do or why either. A repo contains everything for a single project. Not more, not less. For a different projet create an independent repo. For continued work clone the existing repo and just work on the existing branches or create a new branch, depending on the workflow your project or technical lead has decided upon (I often went with either Git Flow or some simplified variant).

The notice in the middle of a merge is really only just a best guess, not an acurate diagnostic. git reset --soft could perhaps be less specific here, since it doesn't go to great lengths to figure out the accurate circumstances.

A central hub when you work locally with Git is the "index" (formerly called "cache"), where Git caches the state of the files in the worktree that it tracks. The index also records the states of files when a conflict occurs during a "mergy" operation.

The thing is, "mergy" operations occur not only during an actual merge that was initiated by git merge, but also by many other operations. A prominent such operation is git cherry-pick. And git stash pop is another one.

The next thing is, there are certain operations that are not permitted when the index contains the records of a merge conflict. The most important operation that is prohibited in this situation is git commit. And, as you found out, git reset --soft is another one. For these operations, it is sufficient to inspect the index to know whether the operation can continue or must be stopped. When they do stop, the emit the error you saw, under the assumption that a merge is in progress. What they actually mean, however, is that you are in the middle of a _mergy_ operation.

git merge, however, is a fancier operation. In the case of conflicts, it not only leaves behind the index in a conflicted state, but it also leaves behind additional state that it needs when the user finally uses git merge --continue or git commit to conclude the merge after having resolved the conflicts. Therefore, git merge --abort has more clues to find out whether you are indeed in the middle of "a merge"; the particular one that you observed is that the file MERGE_HEAD is absent.

Partial answer: you'll lose all the changes you made while running git reset --hard

I would recommend creating a new branch because the following steps could delete some of your changes permanently. Also create a backup of your directory just in case.

First checkout a new branch from your current one, e.g. git checkout -b my-new-branch.

Then hard set your branch to your last commit on your branch before you merged in the other branch: git reset --hard <last commit reference, e.g. 134124124124>.

Then you could cherry pick any commits you made on your old branch after the merge commit, e.g. git cherry-pick 123123123.