1

I have installed Git version 2.8.1.windows.1 and I run it under a MINGW64 bash shell.
I have a remote, bare repository that I push my commits to periodically (actually, almost after every commit). I generally terminate the session by entering a Ctrl-D.

On two occasions, after doing the first commit of the day, when I followed it up with a "git status" command prior to pushing, it showed that I was one commit behind the remote repository (and one commit ahead).
It seems that the last commit I performed the prior day before shutting down was no longer on my local repository although my disk files reflected the most recent updates.

I was now forced to first do a merge with a "git pull" on the remote repository, which clobbered my local files (conflicts) before I could push again.

What should I do to avoid this situation?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Booboo
  • 38,656
  • 3
  • 37
  • 60

1 Answers1

0

one commit behind the remote repository (and one commit ahead)

That means you have somehow diverged: you have local commits that the remote repo does not, and the remote has a commit which you don't have locally.

Since the remote repo is supposed to be your backup repo, the easiest way to resolve the situation (without clobbering your local repos with conflicts after a git pull) is to force push:

git push --force

Considering you are the only one to use (and push to) that remote repo, this is safe.

Also, make sure your git config --global core.autocrlf is set to false, in order to not have automatic eol conversion and modification on all files.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yes, I know, but the question is: How could the two repositories have diverged unless there is a bug given I am the only user? Also, re your suggestion about setting core.autocrlf to false, isn't Git able to distinguish binary from text files? I thought the recommendation for Windows was to set it to true. – Booboo May 01 '16 at 02:52
  • @RonaldAaronson no: core.autocrlf should *always* be set to false: http://stackoverflow.com/a/35268716/6309. Use core.eol gitattributes directive: http://stackoverflow.com/a/3209806/6309 – VonC May 01 '16 at 07:23
  • "How could the two repositories have diverged unless there is a bug given I am the only user?": generally a rebase, reset or other operation which amend an existing commit, rewriting the local history. – VonC May 01 '16 at 07:24
  • The only resets I've ever done were with the --hard option. Had I done such a reset, my local repository would be one commit behind the remote but, that would not explain why my local file still being in sync with the remote and out of sync with the local repository, i.e. it reflecting the missing commit. But I don't believe I did any reset at all having been satisfied with the change. Your recommendation of doing a "push --force" would result minimally in the loss of history, If this new commit is for a change to a file other than one involved in the missing commit, it's a disaster – Booboo May 01 '16 at 10:44
  • If you are satisfied with your local history, just force push, and you are done. – VonC May 01 '16 at 10:46
  • The point I have been trying to make over and over again is that I wasn't satisfied with my local history -- it was missing an important commit that was however reflected in my local file, as if I had done a "git reset --mixed", which I still claim I had not done. – Booboo May 01 '16 at 12:17
  • Sorry, do you see your lost commit after a git fetch? If yes, you can cherry-pick it. If not, check the reflogs on the bare remote repo side. – VonC May 01 '16 at 12:21