git-style diffs broken in 2.5.1?

Matt Mackall mpm at selenic.com
Tue Apr 2 00:29:51 UTC 2013


On Tue, 2013-04-02 at 11:23 +1100, Peter Howard wrote:
> On Thu, 2013-03-28 at 08:24 -0700, Matt Mackall wrote:
> > On Thu, 2013-03-28 at 10:42 +1100, Peter Howard wrote:
> > > On Tue, 2013-03-19 at 00:03 -0500, Matt Mackall wrote:
> > > > On Tue, 2013-03-19 at 09:21 +1100, Peter Howard wrote:
> > > > > On Sun, 2013-03-17 at 15:09 -0500, Matt Mackall wrote:
> > > > > > On Thu, 2013-03-14 at 09:31 +1100, Peter Howard wrote:
> > > > > > > On Wed, 2013-03-13 at 14:50 -0700, Bryan O'Sullivan wrote:
> > > > > > > > On Wed, Mar 13, 2013 at 2:43 PM, Peter Howard
> > > > > > > > <pjh at northern-ridge.com.au> wrote:
> > > > > > > >         The diff in question goes across a
> > > > > > > >         merge but, as I said, I can't reproduce it simply.
> > > > > > > >         
> > > > > > > > 
> > > > > > > > Actually, if you can bisect the Mercurial repo to track down the
> > > > > > > > changeset that breaks everything, that would be a big help. It
> > > > > > > > shouldn't take more than a few minutes of work, and that might end up
> > > > > > > > being enough to figure out the cause.
> > > > > > > 
> > > > > > > Ouch.
> > > > > > > 
> > > > > > > It happened much, much earlier than I noticed . . .
> > > > > > > 
> > > > > > > /wrk/mercurial-play/hg$ ./hg bisect -b
> > > > > > > The first bad revision is:
> > > > > > > changeset:   15775:91eb4512edd0
> > > > > > > user:        Matt Mackall <mpm at selenic.com>
> > > > > > > date:        Wed Jan 04 17:55:30 2012 -0600
> > > > > > > summary:     copies: rewrite copy detection for non-merge users
> > > > > > 
> > > > > > Yes, that's a very likely point for this to have changed. Now what
> > > > > > remains is to demonstrate that the new diff is _actually incorrect_: the
> > > > > > old code was known to be frequently wrong.
> > > > > > 
> > > > > > So we're still back to either getting a repro or attempting to walk you
> > > > > > through a diagnosis.
> > > > > > 
> > > > > 
> > > > > Getting the actual repo: 0% chance :-(
> > > > > Creating a demo repo: I suspect the odds are around 0.1% :-(
> > > > > 
> > > > > So that leaves the diagnosis.
> > > > > 
> > > > > > For the latter, I guess the first thing I'd like to see is, for the
> > > > > > problematic diff:
> > > > > 
> > > > > I think I need a bit more information here - I've tried below and it's
> > > > > not showing up much.  I'm treating "revision 1" as the tip, and
> > > > > "revision 2" as the older revision.
> > > > > 
> > > 
> > > OK, new set of data one my brain started working. Done using 2.5.1
> > > 
> > > > > > 
> > > > > > - revision 1
> > > > > > - revision 2
> > > > > > - hg log -r "ancestor(r1, r2)" (revision 3)
> > > > > 
> > > > > revision 3 == revision 2.
> > > 
> > > Still true
> > > > > 
> > > > > > 
> > > > > > ..so that we can establish the relevant topology. Then I'd like to see:
> > > > > > 
> > > > > > - hg manifest --debug -r r1 | grep oldfile
> > > 
> > > No mention.
> > > 
> > > > > >   hg manifest --debug -r r1 | grep newfile
> > > 
> > > 0a5463acd9fc59731c0f2188a354168ffe92765a 644   {path/to/newfile}
> > > 
> > > > > > - hg manifest --debug -r r2 | grep oldfile
> > > 
> > > e07f9b4a6b0240fb4dbe82e081ee28ac6402fb39 644   {path/to/oldfile}
> > > 
> > > > > >   hg manifest --debug -r r2 | grep newfile
> > > 
> > > No mention.
> > > 
> > > > > > - hg manifest --debug -r r3 | grep oldfile
> > > > > >   hg manifest --debug -r r3 | grep newfile
> > > > > > 
> > > > > 
> > > 
> > > Skipping as r3 == r2
> > 
> > Ok, that looks pretty sane, but perhaps backwards. To confirm, you're
> > doing this, right?:
> > 
> >  hg diff -r r1 -r r2
> 
> I think you were assuming I was using r1 == older revision, r2 == newer
> revision whereas I was doing the reverse.  So I'm really doing
> 
> hg diff -r -r r2 -r r1
> 
> 
> > 
> > What does this do?
> > 
> >  hg status -C --rev r1:r2
> 
> Gives a list of the files differing between the two diffs (including the
> 'moved' file as a R (new name) and A (old name) )

I'd expect to see:

A newname
  oldname   <- line immediately after each renamed file with the source
... 
R oldname

If you don't see that.. well, it may not have been recorded as a
copy/rename. 

But there's a more direct way to check. Here's a copy early in the
Mercurial history:

# find the revision where the file was introduced
$ hg log -r 'first(file("**localrepo*"))'
changeset:   1089:142b5d5ec9cc
user:        mpm at selenic.com
date:        Sat Aug 27 14:21:25 2005 -0700
summary:     Break apart hg.py

# dump its rename metadata directly
$ hg debugrename -r 1089 mercurial/localrepo.py
mercurial/localrepo.py renamed from
mercurial/hg.py:79bd2e10567756efea8c5a37c31369910f170772

-- 
Mathematics is the supreme nostalgia of our time.





More information about the Mercurial mailing list