Git pull overwrites and does not merge or acknowledge conflict on same branch (master)

Question

Background:

I've got what I perceive to be a simple scenario. I've committed changes locally and now I want to merge what's on the remote, in the same branch (ahead of me) into the local, working directory.

git branch -vv --list --all gives the following:

  master                79d9d4e [origin/master: behind 7] Footprint UI working
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master a86a1a9 Added sample data to webpage

There's one file in particular that I'd like to merge. Here's the diff: git diff --stat a86a1a9 79d9d4e views/footprint.handlebars

views/footprint.handlebars | 65 +++++++++++++++++++++++++++++++++--------------------------------
 1 file changed, 33 insertions(+), 32 deletions(-)

But when I run git pull, the version of the file in my local commit is overwritten by that of the remote. In more verbose terms:

$ git fetch -v origin  

From github.com:githubusername/foo
 = [up to date]      master     -> origin/master

$ git merge origin  
Updating 79d9d4e..a86a1a9
Fast-forward
...
 views/footprint.handlebars    | 65 ++++++++++++++++++++++++++++++++---------------------------------
...
 6 files changed, 220 insertions(+), 59 deletions(-)
 create mode 100644 static/search.js
 create mode 100644 views/search.handlebars

I've read over the following posts:

1. git merge overwrites contents
2. Git merge master into development branch is overwriting, not merging

And have tried these commands:

1. git pull --rebase overwrites the local version of the file
2. git merge -s recursive -X ours overwrites local version of file
3. git merge -s ours prompts for commit message and then overwrites remote changes
4. git rebase remotes/origin/master says that it will "replay my work on top of" head, but still overwrites it
5. git merge --no-ff --no-commit literally reports "Automatic merge went well; stopped before committing as requested" when it's overwritten the file

(After running each of the above, I checked the file in question and, noting that it was overwritten, ran git reset --hard master@{"5 minutes ago"})

$ git config --list  

redential.helper=osxkeychain
user.name=My Name
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.precomposeunicode=true
[email protected]:githubusername/foo.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
[email protected]
remote.heroku.url=https://git.heroku.com/foo.git
remote.heroku.fetch=+refs/heads/*:refs/remotes/heroku/*

$ git log --oneline --decorate --simplify-by-decoration --all -10  

a86a1a9 (origin/master, origin/HEAD) Added sample data to webpage
79d9d4e (HEAD -> master) Footprint UI working
c53160d Initial commit

$git log --format="%h %ci %cn" views/footprint.handlebars

79d9d4e 2019-03-12 19:04:08 -0400 chb
fada3fa 2019-03-10 13:59:41 -0700 JA
9641499 2019-03-08 16:48:14 -0800 JA
1759509 2019-03-08 12:32:08 -0800 GitHub
bfe443e 2019-03-07 16:41:18 -0800 JA

git version 2.17.2 (Apple Git-113)

Question:

Why is this conflict not being flagged as such by git, with the appropriate markers (<<<<<<< HEAD, =======, >>>>>>>) being added to the relevant file?

Answer 1

I suspect a misunderstanding about what a merge is supposed to do. (mind the emphasis, and bear with me)

Let's clear it up, if any.

We'd better focus on the file views/footprint.handlebars. Was it changed between the initial commit and your local commit? Between the initial commit and origin/master? Both?

If you didn't change it, the fact that after the merge your file reflects their changes is expected.

If they didn't change it and your changed version is overwritten with an "older" version from initial commit after the merge, now that's an odd behaviour to investigate.

If both you and them have brought changes to the file, but at different, non-conflicting points, then the end result should contain changes from both sides, without conflict. I wouldn't call that "overwritten".

---

Lastly, if you in fact want to keep this file in the exact state it is in your recent local commit, you'd have to, like you hinted at like a very tedious thing, make the merge conflict, but that's not a big deal :

git checkout master
git fetch
git merge --no-commit origin/master
git checkout HEAD -- views/footprint.handlebars
git commit -am "Kept file views/footprint.handlebars as per commit 79d9d4e"

Give us a bit more feedback and I'll edit to adjust. (probably tomorrow, though ;-)

Addition after comments :

I'm pretty much agreeing with Useless' comment down below. I didn't get from your original question that there was back-and-forth on the very file in-between you and your coworker's commits (as you added here).

The solution to restore both your needed changes and theirs might now be to check file history, then rebuild the contents carefully from the initial shared state, but depending on your context it's hard to advise on the best formula. If the coworker is available to sort it out with you, you're likely to avoid a lot of headaches.

Epilogue addition :

Sorry for the bitter sweet ending, I totally understand that you would have prefered a more intellectually satisfying answer/solution. I thank you for the bounty and everyone else for all the insightful comments.