Merge Diff Extension

Matt Mackall mpm at selenic.com
Sun Mar 11 14:40:13 CDT 2012


On Sun, 2012-03-11 at 09:24 +0100, Na'Tosha Bard wrote:
> On Sat, Mar 10, 2012 at 9:53 PM, Matt Mackall <mpm at selenic.com> wrote:
> 
> > On Sat, 2012-03-10 at 21:26 +0100, Na'Tosha Bard wrote:
> > > Hello,
> > >
> > > I know this particular project seems currently unmaintained, but could we
> > > consider something like
> > > http://mercurial.selenic.com/wiki/MergediffExtensionfor core?
> >
> > Is this something people are actively using to review diffs?
> >
> 
> We were before it got out of synch with the API and broke.

I have no idea how this code works or how to read its output (or even
how the patch code works any more!) but it took about 5 minutes to make
it work with both 1.8 and 1.9:

diff -r ea42fd5c9bba mergediff.py
--- a/mergediff.py	Tue Mar 15 11:17:11 2011 -0400
+++ b/mergediff.py	Sun Mar 11 14:05:11 2012 -0500
@@ -39,7 +39,11 @@
     if not diff_str:
         return
 
-    for state, values in patch.iterhunks(ui, StringIO(diff_str)):
+    try:
+        i = patch.iterhunks(StringIO(diff_str))
+    except TypeError:
+        i = patch.iterhunks(ui, StringIO(diff_str))
+    for state, values in i:
         if state == 'hunk':
             hunk = values
             hunk.afile = afile
@@ -50,7 +54,7 @@
             # For some reason, 'iterhunks' gives us the same hunk twice in
             # a row... So ignore the hunk we get with 'file' - it should be
             # picked up by the next "state = 'hunk'".
-            afile, bfile, _ = values
+            afile, bfile = values[:2]
 
         elif state == 'git':
             raise util.Abort("can't deal with the 'git' state yet.")

> The more fundamental problem we need to solve is that merges cannot easily
> be reviewed in their default form.  Perhaps there is a better way to "view"
> what is interesting in a merge, other than the MergeDiff extension, but I
> personally think it's pretty good.  If it were shipped with Mercurial (and
> not 3rd party, and consequently breaking), code review tools would be a lot
> more likely to present this "view" for merges, and humans could actually
> review them.

I agree. The theory behind this extension is.. a little fuzzy but
basically ok. But I would frankly tweak the output to be less diff-like
(there's no chance in hell it'll ever work with patch) and more
user-friendly.

As always with third-party extensions, we're going to need the
third-party to sign off on inclusion, and someone to take responsibility
for pushing the inclusion and ongoing maintenance.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list