1

I'm new to the git world and here is a very weird commit conflict problem which is happening to me all the time. I use git through eclipse. It is pretty weird so I try to explain it simply. Here is what I've done

  1. checkouted source from remote to local branch
  2. made some change to the file A.java and did the commit-push A new commit was created and pushed to the remote. Everything was just normal.
  3. made sure that nobody made any change or pushed new commits
  4. made some change to the file A.java again and did the commit-push again
  5. then it told my present local version was not fast-forward and a conflict had been caused, the file A.java

Here is the history 

origin source ------- second commit-push

      |
      -------- first commit-push

The second commit-push's parent was not the 'first commit-push', which was so confusing. Wasn't it supposed to be the 'origin source'?

And this weird phenomenon doesn't just happen to successive commit-pushs for the same file. It's happening to every commit-pushs. A new commit-push I create start from the second newest commit instead of the newest one and an auto-merging will be created if there is no conflicts within my commit and the newest one.

Anyone can tell me what is happening and why it is happening?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Luke_Z
  • 11
  • 2
  • You couldn't have a merge conflict locally unless you pulled. So, did you also pull? – Tim Biegeleisen May 02 '17 at 03:25
  • That was confusing. What I described really looked like a simple mistake. But I did pull and make sure my local was the newest though my local was already the newest because there was no someone else dealing with this branch only me. – Luke_Z May 02 '17 at 09:20

1 Answers1

0

The second commit-push's parent was not the 'first commit-push', which was so confusing

That can happen if someone else has forced a push (git push --force), effectively replacing your first pushed commit by his/her.

The best approach in that case is a git pull --rebase, which will replace your local commit on top of the new origin/master, and then git push.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you for your answer. But there's no someone and I'm sure about that because it is only me dealing with that branch. And even if I do replace my local commit on top of the new origin/master, that phenomenon still happens... – Luke_Z May 02 '17 at 09:06
  • I can't appreciate more for reediting my question format. New here and still a long way to go. – Luke_Z May 02 '17 at 09:22
  • @Luke_Z Does the issue persists when doing the same push in command line? Can you do a `git config --global core.autocrlf false`, clone your repo again, import it to Eclipse and try again? – VonC May 02 '17 at 10:50
  • Thank you. I've never tried it in command line. I'll make a try. It's goons be next week but I'll keep you updated. – Luke_Z May 03 '17 at 05:39
  • I'm so sorry to tell that I'm not able to try command lines in the eclipse of my developing environment because those plugins are not available here. Anything else I can do or check only by the egit? – Luke_Z May 08 '17 at 23:53
  • @Luke_Z No plugin needed. Simply install Git (for instance, on Windows, unzip https://github.com/git-for-windows/git/releases/download/v2.12.2.windows.2/PortableGit-2.12.2.2-64-bit.7z.exe anywhere you want) – VonC May 09 '17 at 04:31
  • I checked what you said from the last comment. It had been set already, 'git config --global core.autocrlf false', and I had done cloned that repo again, which didn't work last time. But I have something to add here. The last time I deleted and cloned the repo, the 'git config-- repo settings' went wrong and I revised it by hand. There's also a 'core' key word, like 'core.filemode false, core.logallrefupdates true, core.repositoryformatversion 0, core.symlinks false'. – Luke_Z May 09 '17 at 23:47
  • Recently I finally found some fundamental weird movement which caused this issue. I tried not to push to the remote and only do some commits locally. And this happened: after I committed the second time, my first local commits disappeared and the files included in the first commit appeared in the commit list of the second commit. Is this a consequence of some setting I accidentally made in git configuration? – Luke_Z Jun 29 '17 at 02:47