<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-13 22:08 GMT+02:00 Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[...] I hadn't looked at how to actually go about writing the "bug-free" merge tool (if it becomes possible to write one).</blockquote><div><br></div><div>Isn't the whole approach limited by Rices's theorem? (<a href="https://en.wikipedia.org/wiki/Rice%27s_theorem">https://en.wikipedia.org/wiki/Rice%27s_theorem</a>) In general we have to deal with partial functions, and the property you're talking about is definitely not trivial in the theorem's sense. So this implies 2 choices:</div><div><br></div><div>   * You don't detect all problems caused by merging (no point in putting some effort into that approach, it's basically what we have today with plain 'git merge').</div><div><br></div><div>   * You have false positives, i.e. the merge tool complains although the merge is OK.</div><div><br></div><div>So the best you can do AFAICT is to keep the amount of false positives low, hoping that people will see a benefit for the added annoyances.</div></div></div></div>