git local master branch stopped tracking remotes/origin/master, can't push

Just when I thought I'd got the hang of the git checkout -b newbranch - commit/commit/commit - git checkout master - git merge newbranch - git rebase -i master - git push workflow in git, something blew up, and I can't see any reason for it.

Here's the general workflow, which has worked for me in the past:

# make sure I'm up to date on master:
$ git checkout master
$ git pull # k, no conflicts
# start my new feature
$ git checkout -b FEATURE9 # master @ 2f93e34

Switched to a new branch 'FEATURE9'

... work, commit, work, commit, work, commit...

$ git commit -a
$ git checkout master
$ git merge FEATURE9
$ git rebase -i master # squash some of the FEATURE9 ugliness

Ok so far; now what I expect to see -- and normally do see -- is this:

$ git status

# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

But instead, I only see "nothing to commit (working directory clean)开发者_C百科", no "Your branch is ahead of 'origin/master' by 1 commit.", and git pull shows this weirdness:

$ git pull
From .                                        # unexpected
 * branch            master     -> FETCH_HEAD # unexpected
Already up-to-date.                           # expected

And git branch -a -v shows this:

$ git branch -a -v

  FEATURE9                 3eaf059 started feature 9
* master                   3eaf059 started feature 9
  remotes/origin/HEAD      -> origin/master
  remotes/origin/master    2f93e34 some boring previous commit # should=3eaf059

git branch clearly shows that I'm currently on * master, and git log clearly shows that master (local) is at 3eaf059, while remotes/origin/HEAD -> remotes/origin/master is stuck back at the fork.

Ideally I'd like to know the semantics of how I might have gotten into this, but I would settle for a way to get my working copy tracking the remote master again & get the two back in sync without losing history. Thanks!

(Note: I re-cloned the repo in a new directory and manually re-applied the changes, and everything worked fine, but I don't want that to be the standard workaround.)

Addendum: The title says "can't push", but there's no error message. I just get the "already up to date" response even though git branch -a -v shows that local master is ahead of /remotes/origin/master. Here's the output from git pull and git remote -v, respectively:

$ git pull
From .
 * branch            master     -> FETCH_HEAD
Already up-to-date.

$ git remote -v
origin  git@git.company.com:proj.git (fetch)
origin  git@git.company.com:proj.git (push)

Addendum 2: It looks as if my local master is configured to push to the remote, but not to pull from it. After doing for remote in 'git branch -r | grep -v master '; do git checkout --track $remote ; done, here's what I have. It seems I just need to get master pulling from remotes/origin/master again, no?

$ git remote show origin
* remote origin
  Fetch URL: git@git.company.com:proj.git
  Push  URL: git@git.company.com:proj.git
  HEAD branch: master
  Remote branches:
    experiment_f tracked
    master    tracked
  Local branches configured for 'git pull':
    experiment_f merges with remote experiment_f
  Local refs configured for 'git push':
    experiment_f pushes to experiment_f (up to date)
    master    pushes to master    (local out of date)

---

When you do a git pull did you actually want to do a git push?

For some reason git pull is "pulling" from your current directory, I suspect you want to be pulling from remotes/origin/HEAD.

What output does git push origin produce?

[Addendum by Paul]: This led me to the correct answer, so I'm accepting. The additional steps it took to figure out what was going on were:

# see details of the current config:
$ git config -l
branch.master.remote=. # uh oh, this should point to origin
# to see what it should be ,make a clean clone of the same project 
#   in a different directory, checkout the master branch and run the
#   same command. That showed "branch.master.remote=origin", so...

# then to fix:
$ git config branch.master.remote origin

After that, the local master was tracking remotes/origin/master again. Thanks to Peter Farmer for the clue that got me here!

---

Doing some investigation following on from Peter and Nick's comments led to:

# botched local clone:
$ git config -l
branch.master.remote=.
branch.master.merge=refs/heads/master
[...]

# new / clean local clone:
$ git config -l
branch.master.remote=origin
branch.master.merge=refs/heads/master
[...]

Hopefully I can post this as an answer without accepting it (if not I'll have to delete & put it in a comment or the original question). Doing...

$ git config branch.master.remote origin

...got branch.master.remote to =origin again, but it doesn't explain how it got "untracked" in the first place.

If someone can explain cleanly:

a) how my local "botched" repo might have gotten into such a state given the workflow in my question, and

b) the right sequence of actions to get back in sync safely (given that the remote head could have advanced in the meanwhile), I'd like to mark that as the accepted answer, as I think it would be most useful to others in this situation.