On Sat, Nov 02, 2013 at 03:11:55AM +0200, Gerasimos Dimitriadis wrote: > Hi, > > I have a question on the order with which commits are applied on a merge. > > I am merging two branches that have changes on the same text file and > I'd like to ask you about the merge result. > > The following output is provided on the two branches to be merged, by > the command: > git show-branch --date-order branchA branchB > > ! [branchA] file.txt got form A > * [branchB] file.txt got form B > -- > + [branchA] file.txt got form A > * [branchB] file.txt got form B > + [branchA^] file.txt got form B > +* [branchA~2] First version of file.txt (form A) > > Now, this text file alternates between the following contents: > > According to form A, file.txt contains only one line of text: > Gerasimos > > According to form B, file.txt contains three lines of text: > PL-3 > PL-4 > PL-5 > > The merge is done with the following commands: > git checkout branchA > git merge branchB > > Now, the result of the merge gets file.txt to form B, i.e. it contains > the above 3 lines of text. > My question is, why does the merge have the file resolve to form B and > not to form A ? > Theoretically, the merge could resolve to either A or B form. If the > date is taken into account, maybe the A > could even appear to be a better result. I'm going to try to explain this, but I might be wrong, and I'm sure someone will correct me if I am. git computes a merge base from the two branches, and that commit is branchA~2. Now, the net change in branchA is nothing; that is, the file is exactly the same at the merge base as it is at the final commit of branchA. branchB, on the other hand, has made a change, to form B. git only considers three points here: the merge base and the two branches being merged. So since there is a change on branchB, but no change on branchA, git applies the changes introduced by branchB, and you get form B, since a merge applies the changes in both branches. The trivial case where a change has been made in one branch but not the other means that change is applied. git doesn't care about intermediate changes here, since it doesn't consider them. In some cases, git can consider multiple common ancestors when using the default recursive strategy, but that doesn't apply here. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature