Hi, On Wed, 7 Jan 2009, Pierre Habouzit wrote: > On Wed, Jan 07, 2009 at 10:00:07PM +0000, Johannes Schindelin wrote: > > Therefore I counted the lines between conflict markers (actually, a perl > > script did). Of these 66 merges, on average patience merge produced > > 4.46774193548387 _fewer_ lines between conflict markers. > > > > Take that with a grain of salt, though: the standard deviation of this > > difference is a hefty 121.163046639509 lines. > > > > The worst case for patience diff was the merge > > 4698ef555a1706fe322a68a02a21fb1087940ac3, where the --cc diff line counts > > are 1300 (without) vs 1301 (with patience merge), but the lines between > > conflict markers are 197 vs a ridiculous 826 lines! > > > > But you should take that also with a grain of salt: this merge is a > > _subtree_ merge, and my test redid it as a _non-subtree_ merge. > > > > So I restricted the analysis to the non-subtree merges, and now > > non-patience merge comes out 6.97297297297297 conflict lines fewer than > > patience merge, with a standard deviation of 58.941106657867 (with a total > > count of 37 merges). > > > > Note that ~7 lines difference with a standard deviation of ~59 lines is > > pretty close to ~0 lines difference. > > > > In the end, the additional expense of patience merge might just not be > > worth it. > > Depends, if it can help generating nicer merges, it's good to have. > > We could have an option to git-merge that tries hard to generate the > smallest conflict possible. I also showed you examples, in addition to numbers, exactly to point out that shorter conflicts do not necessarily mean nicer conflicts. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
