I have to agree with your first four sentences. Your prove-it-to-yourself example, however, is quite different from my case where all changes happened in the same branch, and trunk was unaltered (with respect to the lines in question).
Obviously, if the same line of code changes on both sides of the merge, this is a clear conflict. But, in my case, only one side has changed. (The conflict seems to arise from the changes occurring in the same branch and the inability to use all of them due to cherry picking.) Because the cherry pick option was used, only those changes introduced in that particular check-in should be merged (i.e., compared with the other side of the merge). But, fossil apparently sees the end result of that line as affected by previous check-ins even though cherry pick was used. I now see this is a limitation of the merging mechanism that, apparently, can only deal with full line merges. I guess we have to live with that. However, I still feel there was a misleading (if not incorrect) report of the problem. For one thing, the common ancestor content shown seems totally incorrect. But then again, I have no clue which check-in fossil picked to be the common ancestor. Maybe there could a report in that message of the check-in ID chosen as the common ancestor to help debug the issue. A clearer conflict report like “Cherry-picked content carries previous check-ins” or “Cannot cherry pick this particular line” would also be nice. From: Scott Robison Sent: Friday, November 13, 2015 6:40 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Unexpected merge conflict On Nov 13, 2015 9:15 AM, "Tony Papadimitriou" <[email protected]> wrote: > > Sorry for the confusion. > By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing > the merge. > And, I’m merging the “check-in from the ... [other] branch” I mean the > check-in which is part of the other part. > > I think I’m beginning to understand what’s going on. If I do a full merge > (no cherry pick) there are no conflicts. > So, it seems the fact that the SRF_OUT label was renamed in an earlier > check-in that the one I’m cherry picking is confusing it. > What should have happened actually (what I expected with the cherry pick) is > not exactly what I mentioned earlier. > The ‘puts’ change being part of the check-in I cherry picked should have > merged in and the SRF_OUT rename (being from an older check-in) in the > development branch should have stayed out. > > This is a conflict if you look at this line of code as one piece (i.e., you > either merge the whole line or none of it). I believe with 99% confidence that you've hit the nail on the head. Merge is line based. It either merges one or a block of lines as a single entity. It doesn't deal with line fragments. To prove this to yourself, you could create a repo with a single file and a single line of text. Branch it an add a character to the end. Go back to trunk and create a new commit with an new character at the beginning of the line. Try to merge. The same line was modified in both branches so it isn't sure what to do. I'm doing this from memory on my phone, so if I'm wrong, my apologies. And I'll be surprised! :) -------------------------------------------------------------------------------- _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
