After a Git merge conflict, a lot of files I didn't touch become changes to be committed

Question

So I\'m working in a branch, make some changes, and run git merge master. I get a merge conflict on one of the files I modified (which I know how to deal with),

Answer 1

I encountered the same problem myself, and came up with an intermediate solution. Need to find a better one down the road.

First to address the question posed by @NoufalIbrahim: As for " I don't want any of these not-by-me changes to get committed.", why did you do a merge at all if you don't want any changes?

You have misunderstood @grautur intention. The changes are needed, but not as part of a new commit. For example, 1 file was added locally, 100 files came from merge. The new commit should have 1 changed file and not 101 changed file. This is especially important if an automatic merge is not possible, but a pull request is initiated and someone has to review the commit. You want the reviewer to review 1 file, not 101 files.

What I am currently doing is this: let's say we have branch 'master' and 'feature'. 'feature' is created from 'master' and I only make changes to files in 'feature'. When new changes are pulled into 'master', git merge master inside 'feature' will introduce new files (and these are staged automatically in VSCode, which is the IDE I use).

What I do next is unstage all of these files. Basically ignore them. Only add and commit files that I change. Push 'feature' to origin/remote repo, create pull request. When request is accepted and commit is merged to the main branch, delete 'feature' locally and remotely. Pull changes to 'master' local and create a new branch to work on new feature. This new branch will not have a bunch of unstaged files.

There could a git command to tell the git to ignore a bunch of files without using .gitignore. Doing further research into this.