On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford <amb-fos...@bradfords.org> wrote:
> Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600: > > > It is by design. Merging isn't always intuitive, and certainly there > could > > be a bug in it. > > Perhaps like this one: > > http://fossil.bradfords.org:8080/info/b1e9974a37c648fe > > Why was that merge essentially a no-op? > Partly I think it is because your test case consists of a single file of a single line, which means probably (I would think) every merge resulted in a conflict that you had to resolve manually. Here is what I think is happening: [1413f8301f] on trunk leads to [793622de13] on newbranch leads to [2b0c514af3] on newbranch [ec781a493d] on trunk At this point trunk is merged into newbranch resulting in [d228092800]. There had to have been a conflict and the merge was resolved as taking the line from trunk, not newbranch. At this point newbranch has a single file with a single line that came from trunk. There are 5 more commits before [b1e9974a37] which merges newbranch back into trunk, and since newbranch came from trunk during conflict resolution, the nearest common ancestor came from trunk, so trunk wins. Effectively, the line from newbranch was deleted and the line from trunk was inserted, so by the time of the merge there is nothing new or changed in newbranch to merge into trunk. Note that I have not deconstructed and played back all these changes. I have looked at all of the commits though and this is the best I think one can expect a merge algorithm to do with the lines in question. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
