If it would be helpful, I'd be glad to take a look at your repo, or a fabricated repo that demonstrates the same issue. Without the actual current state of the repo, it's hard to know what the exact problem is. Hence my previous guesses.
I didn't write the merge code, but I once upon a time thought I'd found a bug in it, and only several hours of running it under a debugger convinced me that my expectations were at fault, not fossil. I can't say for certain that your problem is the same, but that's what I'd guess. On Fri, Nov 13, 2015 at 2:21 PM, <[email protected]> wrote: > 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 <[email protected]> > *Sent:* Friday, November 13, 2015 6:40 PM > *To:* Fossil SCM user's discussion <[email protected]> > *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 > > -- Scott Robison
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
