On Wed, Mar 18, 2015 at 5:41 PM, bch <[email protected]> wrote: > I tried this, and I see what you're talking about -- It's not clear to > me it's an error (I'm not apologizing for anything that happened here, > but I'd have to better understand the merge algorithm to know if this > is logically sane). Its easy to see how this could be confusing > though. I'll have to fiddle more to understand this. >
Okay, here's what I have come up with. 1. It is not a bug. It is technically accurate, though confusing, because it doesn't allow you to easily "use original" or "use merge" because of the missing line. 2. The "problem" (in my expectation, not fossil) is one of context. I made a little test change to force at least one extra line of context at the end of the conflict block and that gives me what I was expecting. However, I can see where this "problem" could probably crop up with inadequate context at the beginning of the conflict instead of at the end, or that perhaps one extra line of context still wouldn't be enough, or could even be too much. The reality is that nothing can be perfect for 100% of all possible use cases, and in this particular case, I just got unlucky. The merge conflict information as given couldn't support a mechanical "pick one or the other" resolution (which was fine because this particular merge needed a thought out solution, not a mechanical resolution). I'm inclined to just leave it alone and live with the reality. Sorry for yelling fire (or whatever). SDR
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
