First and importantly - I am an utter noob. I won’t be surprised to learn that I’m making a fundamental oversight.
That said, I don’t expect to see the error I’m seeing given my workflow. It doesn’t seem sensible, given that I am the only person with access to the remote (at GitLab.com) and local (my local drive) repos.
I am using TortiseGit on Windows 10 for all my local operations.
That said, here’s what I’m doing:
- Using GitLab.com web ui, create an empty project
- Using TortiseGit git clone. retrieve the empty project to my local drive, getting a folder named with the slug
- Copy in my default .gitattributes, .gitignore, and legacy code files (plain files that have never been in any sort of VCS) to that directory
- Using TortiseGit, add all files in the local directory
- Using TortiseGit, push to the origin
So far, so good - nothing but successes.
- Make changes, and add new files in the local disc - my first updated version of code
- Using TortiseGit, push to the origin
And that’s when I get the message “Updates were rejected because the tip of your current branch is behind its remote counterpart” , and the hint that I should maybe pull again… but the changes I want are present only in my local disc, and no one could have altered the remote.
Anyone have a clue what is happening?
Hi @ITAdminASEI
I would say the Git knows there was a change and you can just do git pull to sync.
You can also check in GitLab UI in Repository -> Commits that there really aren’t any other commits. You will also see hash of the latest commit in your branch. You can compare it to hash you get from git rev-parse HEAD in your local repo.
Unfortunately, due to the proprietary IDE and language I do most of my work in, merges are impossible - so a pull-and-sync would be destructive to my local repo, which has the changes I desire.
I see only one commit at GitLab and locally, but they have different hashes. If memory serves, I tried to push as an amended commit - that might explain different hashs, but not why Git thinks remote is newer than local. At least not to me; there’s lots I don’t understand about Git.
Thanks for the tips! I know more than I did, but still hope to understand all the implications.
You can also try to run git fetch to download history from remote (in case there is some sync issue).
You can run git log on your local repo to see commits history. And git log origin/master to get history from remote master branch.
If you are 100% sure that there are no incompatible changes, another option is to clone the remote repo again to another directory, copy your changes over, commit+push and continue to work in the new clone.
This symptom is not a one-time thing - it’s happened with most of the repos I’ve created, so I need to understand it - particularly since I need to train colleagues unused to SCM as soon as I’m competent. So while a sound idea, just using a new clone won’t do in this case.
Here’s what I got from the commands you’ve suggested, edited slightly for business privacy:
User@DESKTOP-ID MINGW64 /c/GitLab/ebr (master)
$ git fetch
warning: redirecting to https://gitlab.com/customer-name/location/site/ebr.git/
User@DESKTOP-ID MINGW64 /c/GitLab/ebr (master)
$ git log origin/master
commit 6c669acab6b5a95de398b1941f57858bbb15bc8a (origin/master)
Author: User User@org.cc
Date: Wed Jun 2 13:47:53 2021 -0400
Initial commit
User@DESKTOP-ID MINGW64 /c/GitLab/ebr (master)
$ git log
commit 718386fc668af52fc209eb891d37eb56bec86346 (HEAD → master)
Author: User User@org.cc
Date: Wed Jun 2 13:47:53 2021 -0400
Initial commit
With binaries
User@DESKTOP-ID MINGW64 /c/GitLab/ebr (master)
$
If I read that right, there are two commits locally and only one remote, which makes sense, since I added binary files and amended the first commit locally. It is the attempt to push that amended commit that gives the error.
I see only 1 commit on both sides. The commit hashes differ, because you did amend to the local one.
Commit amend rewrites git history. Now, I assume that this really happened: you did a commit, pushed it to remote and then did amend to that commit. This is the reason you get that message. Now the remote and local git history doesn’t match and git is complaining. You really shouldn’t amend to commits that have been already pushed to remote. It’s bad practice and causes a lots of issues.
This can be solved with merges, but you mentioned that merges are not a good option (more on this later). I guess your only option is to force push using git push --force. This will rewrite the remote history to match the local. This is another kind of last resort thing to do 
, because if someone else did some changes and pushed them they will be lost.
GIT is based on Merges and actually it’s core workflow is based around merges. If merges are not an option for you, you might want to look for a different SCM.
Much obliged! I think you’re right, and it’s not the first time I’ve had this thought. My typical file types are far outside the designed intent of git. I’m looking at revising my plans and putting only the HTML and C# portions of our development in git; that should make it much easier to learn what to do.
That said, and even knowing as I now do that amending a commit post-push is not a good idea, isn’t the error message misleading? "because the tip of your current branch is behind its remote counterpart” to me specifically says that the remote had more recent changes (false) not simply that it is different (true). Is this fallout specifically from the amendment? Had I never amended, but instead committed again and then pushed, would all have been well?
I guess the error message could be more specific, but that’s up to GIT developers.
Had I never amended, but instead committed again and then pushed, would all have been well?
Yes