How to ignore unmerged paths?

Question

Currently I'm working with yii and I use git center repository, let's say in development config is set to localhost, and in production server config is set to server ip.

I have modified file which need to commit

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   backend/modules/company/controllers/XyzController.php

When I commit, I get error

U       backend/config/main.php
U       frontend/config/main.php
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

here is Unmerged paths

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   backend/config/main.php
        both modified:   frontend/config/main.php

because it conflict with production server config when I pull from center repository.

I have already include backend/config/main.php and frontend/config/main.php in .gitignore but no effect.

so How can I solved it so I can commit only XyzController.php and push to remote?

If I commit backend/config/main.php and frontend/config/main.php then it will included in push. and it think it will conflict when in production server I pull from center repository.

Thanks in advance.

Answer 1

If you have unmerged paths due to a git stash pop you can resolve the conflicts manually on that file and then do a git reset filename

Answer 2

An unmerged path means you have run git merge, or the equivalent of git merge, and it tried to merge two different sets of changes to that file, but failed.

This means that you must now combine the two sets of changes in that file. Git will have left behind, in your work-tree, its best effort at combining the two sets of changes, but Git is quite certain that what it left behind is not correct. You then mention:

let's say in development config is set to localhost, and in production server config is set to server ip ...

If the conflict is over the IP addresses in a configuration file, Git is right: it will not have resolved the conflict properly.

The danger is that by putting these files in as version-controlled files, a future git merge operation will think it has resolved a merge correctly when instead, it has put the wrong IP address in.

Configuration files should not be version-controlled. See Committing Machine Specific Configuration Files for one good way to do this. There are others; e.g., you can commit config.sample rather than config.php and have config.php as an ignored file, that each user must write based on the version-controlled config.sample.

In the meantime, however, you still have to clean up the existing mess. The merge conflict occurred because these two files are already version controlled. Unless version-controlling them was your own mistake as part of writing the one change you just made—which seems impossible¹—you should undo the version-controlling as a separate operation (independent of other changes).

Thus, you might use this procedure: Open the two conflicted files backend/config/main.php and frontend/config/main.php in your editor and check the configurations carefully. Fix them as needed, and save the result. Then use the commands:

git add backend/config/main.php
git add frontend/config/main.php

to put the corrected versions into place. It's likely that they now match the previous versions on the current branch, so that git status will no longer show them at all. (If git status does show them, use git diff --cached to see what you have changed.) In any case, this will mark the two files as fully resolved in the index. You can now make a new commit. If the two config files match the ones in the current (HEAD) commit, the only thing changed in your new commit will be the file backend/modules/company/controllers/XyzController.php.

(Remember, a commit has a complete snapshot of every committed file. The next commit you make is based on whatever is in the index right now, i.e., whatever you git add. Once you make the commit, the new HEAD commit and the index now match, so that git status says that there is nothing to commit.)

---

In order to get a merge conflict, the file must be present in both tip commits, or in the merge base and one tip commit, or in all three commits. Remember that a merge works from three versions of each file:

• the merge base version, which is the one that was in place before either branch began to diverge;
• the --ours version, which is the one in the HEAD commit; and
• the --theirs version, which is the one in the other branch tip.

If you mistakenly added a configuration file to your branch, but it was not present in the base and is not in --theirs, there would be no conflict. Therefore, it must be in at least one of the other two commits. Presumably you did not write the base version yourself, nor did you make the other branch-tip commit. If that's true, you could not have caused this configuration-file-is-now-version-controlled issue in the first place.

Answer 3

You can Add only your XyzController.php files, Commit, Push.

$ git add backend/modules/company/controllers/XyzController.php
$ git commit -m 'Added XyzController'
$ git push origin HEAD

It's better to Pull remote changes. If conflict occures in backend/config/main.php, frontend/config/main.php files then resolve conflicts, Add, Commit.

If you want to keep your changes of the files then, accept ours while pulling.

$ git pull origin <branch> -s recursive -X ours    # accept your changes