0

I am facing weird behaviour in git merge when resolving conflicts in some big files where some lines of code from the incoming branch are simply ignored generating syntax and other errors.

One of the various examples :

Following is the code current branch : (stage which is never directly worked on)

Https.post(SERVER_URLS.someSync(queryParams),headers,bodyData,new ResponseHandler({req:null,res : null},function(body){
              },function(err,result){

              }));

Following is the code on incoming branch : (prod also never been worked on directly)

Above code only, just commented.

 // Https.post(SERVER_URLS.someSync(queryParams),headers,bodyData,new ResponseHandler({req:null,res : null},function(body){
 //           },function(err,result){

//            }));

But merge conflict is giving me following choices while merging :

<<<<<<< HEAD
                    Https.post(SERVER_URLS.someSync(queryParams),headers,bodyData,new ResponseHandler({req:null,res : null},function(body){
                      },function(err,result){
=======
                    // Https.post(SERVER_URLS.someSync(queryParams),headers,bodyData,new ResponseHandler({req:null,res : null},function(body){
                    //   },function(err,result){
>>>>>>> production

As you can see, the last closing brace line is left as it is while it is commented in the production branch.

                      }));

Ideally it should also have been included in the conflict choices.

This way I have to be very cautious about the code that is not in the conflict options and quite many times have to edit it too to successfully resolve the conflict.

Have already tried merge options with -Xignore-all-space and -Xignore-space-change but no effect.

I am using git for over 2 years but now such problems are becoming frequent in the team as the project grows. (Not a very advanced user though as the team is fairly small)

This sometimes also break things on production as resolving conflicts is getting very tricky. So any help would be greatly appreciated.

NOTE : GIT version is 2.14.x . Some team members are using 2.6.x but I think this should not be the issue as git metadata is back-compatible and has rarely changed.

Nishant
  • 13
  • 4
  • Did you resolve the merge conflict and complete the merge? If you did, was the braces merged correctly or not? Or did you simply stop and ask this question when the merge conflict didn't include that line? – Lasse V. Karlsen Nov 09 '17 at 09:30
  • 1
    If there is only one change to that line, on one branch, like the commenting out, then this isn't a merge conflict. The other lines was likely changed in both branches, one branch commented out those lines, the other branch changed those lines in a different way. This is a conflict, but if there is only one change on one branch to the line with the braces, that is not a conflict. – Lasse V. Karlsen Nov 09 '17 at 09:31
  • Like I mentioned,the merge in such cases is to be completed by manually commenting the left out line and accepting the production changes. Also this conflict is reported by git only and is not made up. The branches were merged after a weeks time and this is not an incremental change. May be that's why there is this conflict reported. Like one user commented while other one left uncommented. – Nishant Nov 09 '17 at 10:07

0 Answers0