Git Pull merge changes directly, even with conflicts?

Question

I have some local changes and I know the repo has moved ahead since my last pull. When I do git pull, i get below message -

$ git pull
Enter passphrase for key '/c/Users/xxx/.ssh/id_rsa':
remote: Counting objects: 65, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 65 (delta 29), reused 0 (delta 0)
Unpacking objects: 100% (65/65), 16.35 KiB | 7.00 KiB/s, done.
From bitbucket.org:abc/someproject
   ashljkl..db9e852  feature/somefeature -> origin/feature/somefeature 
error: Your local changes to the following files would be overwritten by merge:
        src/main/java/com/somefilepath
Please commit your changes or stash them before you merge.
Aborting
Updating ashljkl..db9e852

From this SOF post: How do I ignore an error on 'git pull' about my local changes would be overwritten by merge? I could figure out how to resolve this issue. 1) git stash local change 2) git pull 3) then git stash pop the stashed changes.

But I want to know if there is an further easier way of handling this - just say to git pull with some options/flags to merge the changes from repo with my local changes directly. In the process of merging, if there are conflicts, i am fine with git showing conflicts and placing conflict markers in the source files that have conflicts.

[`git pull --autostash`](https://git-scm.com/docs/git-pull#Documentation/git-pull.txt---autostash) will stash your local changes and pull in new changes. not sure if there are any options thing that will merge automatically with a pull. In any case git seems to complain of a conflict during merge. — Asif Kamran Malick, Apr 04 '21 at 09:54
@AsifKamranMalick that option is there in the Q I linked. I don't want to use stash. I am looking for direct merge. — , Apr 04 '21 at 10:15
The issue is that you have uncommitted changes. I don't believe git entertains merging uncommitted changes. Git looks for a clean working tree. You need to tell it explicitly what to do with the uncommitted changes. But I am also interested in knowing the workaround. Lets hope someone chimes in. — Asif Kamran Malick, Apr 04 '21 at 10:26
You have a few options, delete, stash, or commit the changes. — evolutionxbox, Apr 04 '21 at 13:04
As far as I know, _all_ git commands are local except pull, fetch, and push. — evolutionxbox, Apr 04 '21 at 13:11
@evolutionxbox: `git ls-remote` and some cases of `git remote` will reach out to a remote as well. I always say that `git pull` means *run git fetch, then run a second Git command* so as to have the fetch step cover the remote access. These days that's less obvious, now that `git pull` is a C program that *shares* the fetch code, vs the old days when it was a shell script that literally ran `git fetch`. :-) — torek, Apr 04 '21 at 19:46
@Victor: there is no direct merge available here. The reason is simple enough: Git actually operates based on *commits*, not on what's in your working tree. However, `git merge` itself needs to use your working tree, so it needs to be "clean" (have nothing uncommitted). The same is true of `git rebase`. So you either use `git stash`—which makes *commits* and then does a `git reset --hard` to achieve the "clean" state—or you make your own commit(s) to get to that same clean state, and then you can run the second command that `git pull` runs. — torek, Apr 04 '21 at 19:54

score 1 · Accepted Answer · answered Apr 04 '21 at 23:58

There is no simple easy way to do this. The simplest, best way to go about this is to stash your changes, and then pull.

The reason this is the case is that any sort of merge that happens here involves the index. The merge would write changes into the index and then check out the files. Your changes may or may not be in the index. If you have not run git add on that particular version, it will not be in the index, and any merge operation would destroy it during the checkout rather than actually performing a merge.

If those changes are in the index, you could try to do a git fetch and then perform a merge yourself with git read-tree -um, checking out the files. However, in this case, the three-way merge that Git does isn't the same as a normal recursive merge, so you lose any ability to have things like renames work. As such, while this is possible, it's not a good choice, and you will likely be unhappy with the results. You'd also have to do the merge base calculation yourself (or script it), which is a bunch of hassle.

So the best solution is to stash here.

this answers - `The reason this is the case is that any sort of merge that happens here involves the index` +1 — , Apr 09 '21 at 05:22

Git Pull merge changes directly, even with conflicts?

1 Answers1