On Thu, Mar 19, 2015 at 9:32 AM, bch <[email protected]> wrote: > > 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). > > This is what I was leaning toward. > > > I'm inclined to just leave it alone and live with the reality. Sorry for > yelling fire (or whatever). > > Thanks for filling a reasonable report - I think the next step is > developing a *workflow* that illustrates what's going on: i.e.: select you > edits, run a diff to see what the changes really are. One thing that struck > me is that code references (i.e.: "last common ancestor") could stand to > have their SHA1 identifier included in the header so I've got it for > immediate reference. > And to be clear that's the sort of thing I do (and what is typically necessary). As I've thought more about it, I think the reason for the disconnect for me in my head (not having dealt much with merge conflicts in the past) is that the merge conflict block greatly resembles a diff between two revisions, yet it is not a traditional diff (and thus does not replace the need for actual analysis via traditional diff between the baseline & each of the two descendants, possibly more).
No biggie. Just a little embarrassment for crying wolf. But the good thing is that I understand the merging code and rationale a lot better now than I did 24 hours ago. :) -- Scott Robison
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
