9

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)", 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)
Paul Smith
  • 3,104
  • 1
  • 32
  • 45
  • 2
    Could you add the output from `git remote -v` to your question. – Peter Farmer Mar 09 '11 at 09:19
  • 1
    Also, you question title refers to problems with `push`, but you don't have any information about error messages with `push`. – Peter Farmer Mar 09 '11 at 09:40
  • 2
    You need to be careful with rebasing branches that track remotes (i.e. your `master` branch) because that will rewrite history and it's possible to confuse either yourself or your remote-repository. If you want to squash commits you might want to squash them on the feature branch *before* merging it to master until you're more comfortable with what it does. – nickgrim Mar 09 '11 at 10:28
  • 1
    @nickgrim: Good advice. My goal was to do a bunch of messy work on the feature branch, then merge that into master, then "denoise" the commit log before pushing by squashing many of the feature commits into 2 -3 meaningful messages. That would give me the (messy) granular history locally, while I wouldn't have to inflict it on the rest of the team. Is there a better workflow for achieving that? – Paul Smith Mar 09 '11 at 18:57

2 Answers2

6

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!

Paul Smith
  • 3,104
  • 1
  • 32
  • 45
Peter Farmer
  • 9,020
  • 5
  • 27
  • 29
  • 1
    My goal was to merge in remote changes before pushing, to verify the build. The remote got ahead of me, but your `git push origin` suggestion made me try `git pull origin`, which resulted in "You asked to pull from the remote 'origin', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line." `git pull origin master` brought some stuff down, and `git push origin' gave me "b1f6453..3b2d904 master -> master". Any idea how to get pull/push to track the remote correctly again? – Paul Smith Mar 09 '11 at 19:17
2

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.

kenorb
  • 155,785
  • 88
  • 678
  • 743
Paul Smith
  • 3,104
  • 1
  • 32
  • 45
  • 1
    I had this happen to, but I was not trying to merge anything other than local branches. It would be good to know what causes this change. – awm Nov 14 '12 at 14:40