0

BACKGROUND

We have dev, qa, prod and feature branches. When we create new feature branches we use prod as our base branch. Our prod branch always contains the latest code that is in production.

One of our developers is working on a feature branch that is taking a few months. Each time the prod branch is updated, he merges the prod branch into his feature branch.

ISSUE

Yesterday, he merged prod into his feature branch and he noticed that changes to some files in the prod branch were not reflected in his branch. Files that he did not modify in his branch were chosen over files that were updated in the prod branch. We are trying to figure out why.

One file has the following history on the prod branch...

commit 19e90b87c4e62ec772a8141789f34c608aa45013 
Date:   Mon Aug 10 14:28:07 2015 -0500    

commit 78cc39d513ee357f416d09137e88cfcc2c33196e 
Merge: ef23ce7 adc3177 
Date:   Thu May 7 08:45:12 2015 -0500

After merging prod into his feature branch and looking at the log for this file in his feature branch, the history starts with the following commit.

commit 78cc39d513ee357f416d09137e88cfcc2c33196e
Merge: ef23ce7 adc3177
Date:   Thu May 7 08:45:12 2015 -0500

I'm not sure why commit 19e90b87 is not included in the merge from prod to his feature branch, when he never changed this file in question in his branch.

I'm continuing to research but any ideas would be appreciated.

RDotLee
  • 1,083
  • 2
  • 15
  • 32
  • Have you checked file permissions? Read about `core.filemode` config option. – ezaquarii Oct 22 '15 at 21:20
  • @ezaquarii : The value is currently false. I changed it to true, performed the same actions as my developer friend and got the same results. – RDotLee Oct 22 '15 at 21:45
  • Can we assume that he did not supply any `-s` or `-X` options that would have such effects? (`-s ours` means "ignore all changes on the merged-in branch" and `-X ours` or `-X theirs` means "resolve conflicts by just using ours-or-theirs respectively".) I don't think this is the problem, just want to clear those away entirely at this point. – torek Oct 22 '15 at 22:15
  • I was able to verify that no options are being passed on the command line. The command being executed is git merge prod while the feature branch is checked out. – RDotLee Oct 23 '15 at 09:40
  • @torek : One thing I just noticed. The merge commit created when merging prod into the feature branch has two parents. I can see where the difference for the file in question (committ 19e90b87) exists in the parent, but not in the merge commit. I must be missing something because I would expect all content changes in both parents of a commit to be part of the history of the file. – RDotLee Oct 23 '15 at 10:39
  • 1
    Your issue seems different from the one I addressed in http://stackoverflow.com/a/33292088/1256452 but you might read through that to see what `git merge` does. The main thing to do first is to find the original merge base and run two `git diff`s from the original base to the two branch tips in question. This does, however, assume that there's a single best merge-base; if there are cross merges you can get into a situation where there are two bases, and then git uses a "virtual merge base". I left this out of the other answer since it's a bit esoteric, but you might be doing cross-merges. – torek Oct 23 '15 at 10:45
  • @torek - i'm looking at the post you referenced thanks. I will look at cross-merges also. – RDotLee Oct 23 '15 at 16:59
  • @torek. I found the original base and did a git diff from this base to the tips of each branch. Very interesting results. From the base to my feature branch are hundreds of diffs. The results did show the commit I originally discussed in my question as being a diff between the feature branch and the base. Now i'm trying to figure out why. – RDotLee Oct 23 '15 at 21:59
  • @torek, the merge section on the link you shared in your previous comment make more sense now that i did the exercise of finding the base and performing the diff. i'm still trying to wrap my mind around your detailed response about how the merge works. Thanks for your input. – RDotLee Oct 23 '15 at 22:11

0 Answers0