Git master ahead of origin/master weird problems-CodePudding

Hopefully, someone can help me out because I've tried a bunch of things and it appears my system is in some weird state.

The way I am running the system, I am running, essentially, a test environment on my local computer. I do various changes etc locally. I then push to bitbucket, ideally making origin/master the ideal production branch.

The Production server I utilize pulls only from origin. There are no changes made on the production server, so there are no unpushed commits.

The link between my local test environment and the origin works as expected. I'm doing it through GitKraken. I can see the origin/master and local master, and various other branches and they are all where I expect them to be.

The problem is the production server:

When I run "git pull http://.......bitbucket....git master It pulls everything down and acts like it is in the correct commit for origin/master.

However, it says it is 26 commits ahead of origin/master.

I tried running git branch -a and it shows 1 local branch and 2 remote branches. However, there should be four remote branches, not 2.

Additionally, it seems like I can do anything to pull the correct origin/master location. It always thinks it is at the commit 26 behind.

I have tried git reset --hard origin/master, and that put me to what it thinks is the origin/master, the commit 26 behind where it should be.

My theories as to why this is occurring are as follows:

The commit it is stuck on was the last commit by the previous developer. The repo was set up by this previous dev and his account. My account has admin access to the repo, but I was wondering if there could be a cause here.
There is a git command I'm not using properly that is meant to pull information from the origin.

Any suggestions are appreciated.

Edit: Some clarification on recent comments.

git fetch, git pull, git fetch origin

all provide the following error:

fatal: could not read Password for 'https://[email protected]': No such device or address.

I can only seem to get anything by running:

git pull https://{username}:{password}@bitbucket.org/{account}/{repo}.git master

I was under the impression that if my 'git pull ....' command is working, then it should run a git fetch at the same time, updating the remote branches correctly.

Running "git reset —hard origin/master" pushes me back to the commit 26 commits behind the correct one. (presumably because git fetch is failing)

After reading comments perhaps there is a problem with my git/config.

See below:

   [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
   [remote "origin"]
    url = https://{username}@bitbucket.org/{account}/mii.git
    fetch =  refs/heads/*:refs/remotes/origin/*
   [branch "master"]
    remote = origin
    merge = refs/heads/master

CodePudding user response：

First fetch all the updates from the remotes

git fetch

If you do not have any local changes run below, to reset you local branch to the version on master

git reset --hard origin/master

After that try a, git pull it will say that branch is already up to date

CodePudding user response：

As ElpieKay noted and matt asked about in comments, the culprit here is your use of a raw URL:

git pull http://.......bitbucket....git master

It's important to remember a number of separate things here:

git pull = git fetch a second command of your choice.
git fetch is what obtains commits and updates remote-tracking names like origin/master.¹
For git fetch to update remote-tracking names, git fetch must be given a remote name like origin.

In particular, if you give git fetch a URL, Git will not look to see if some remote in your .git/config has that URL. It will just connect directly to whatever answers at that URL, and obtain commits from there. Since there's no remote involved here—remotes are the names like origin—as there's only a URL, Git will not update any remote-tracking names (which are more or less² formed by shoving the remote name, origin, in front of the branch name that git fetch can see when whatever answered at the URL lists out their branch names).

The end result is that your own origin/master—the one that you're now seeing as being "ahead of"—remains sadly out of date. Running git fetch origin instead of git fetch http://... will fix it. This is true even if you invoke git fetch via the fancy git pull two-commands-in-one operation.

¹Git calls these remote-tracking branch names, in modern documentation (older Git documentation does not have a consistent term). But they're not branch names, so this is like calling an automobile a "mechanized horse carriage" because it emulates the old horse-powered carriage.

²It's both more and less, for hysterical reasons having to do with the tortuous path by which "remotes" and "remote-tracking names" came about in Git. In particular the "refs" on the remote go through a mapping specified by one or more refspecs. The default refspec for a remote named R transforms refs/heads/text into refs/remotes/R/text, but you can build your own refspecs, and if you do, Git obeys them.