The following Windows batch file will reproduce the condition I’m talking about (f = fossil): ------------------------ f new sample.fossil f o sample.fossil echo Hello > hello.txt f add hello.txt f com -m Initial echo Hello, World > hello.txt f com --branch other -m "Added World!" echo Computer said: Hello, World > hello.txt f com -m "Added 'Computer said'" f up trunk f me other --cherrypick ------------------------ From: Scott Robison Sent: Saturday, November 14, 2015 2:17 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Unexpected merge conflict
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 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 -- Scott Robison -------------------------------------------------------------------------------- _______________________________________________ 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
