Detecting renames

[Matt Mackall]

On Sun, 2010-06-06 at 22:26 +0200, Dirkjan Ochtman wrote:
> On Sun, Jun 6, 2010 at 22:07, Matt Mackall <mpm at selenic.com> wrote:
> > What is up with Mozilla that we never seem to hear from them directly?
> 
> Actually bhearsum just filed a bug the day before yesterday, we hear
> from timeless pretty much every day, bsmedberg has filed bugs before,
> Callek has filed bugs before and dbaron speaks up on the mailing list
> now and then. So it's not all bad, but yes, they could do better.
> Theirs is a bug community, though, and also apparently they have a
> model where they make me responsible for upstreaming most stuff that's
> an issue for them.

Ok. It's useful for us to have some idea what community things are
coming from so we can get a sense whether there are problems that are
plaguing particular communities/development models.

> > I'd rather not. It's the wrong fix and it means growing an option that
> > we'll have to nuke when we fix it right. The right fix is computing a
> > proper filelog graph.
> 
> Sure, that would be even better. You have ideas for that, right?

Yes, but they're not finished yet. If someone wants to take a stab at
it, I can do a brain dump.

> > For now perhaps we should just make annotate slower unconditionally.
> 
> That might work, but if your ideas for the other thing can be
> implemented semi-quickly it doesn't make much sense.

Just for my curiosity, take a look at the speed of hg log -r 'file(foo)'
on the Mozilla repo and see if that's a reasonable overhead.

> > I suppose. Though I think addremove is basically always the wrong thing
> > to use. It mostly exists so I could untar a series of tarballs into a
> > tree in early versions.
> >
> > I'd rather see us move towards making merge smarter and detect
> > unrecorded renames.
> 
> That won't help the simple case, though, right? Where I want to move a
> whole lotta stuff around and not use hg (because that gets tedious),

Well yes and no. It won't be perfect, but it works well enough for that
other SCM...

Frankly, I think git's take on rename tracking is pretty reasonable. And
we take a similar approach in many areas. Users invariably forget to
tell an SCM about things like files being binary, file encoding, newline
mode, how they've moved files, etc. They don't realize there's a problem
until it's too late (ie the next merge). And by that time, it's way too
late to fix things. 

There's definitely value in recording renames in the traditional way,
but I don't think there's any reason not to also guess where we can.

> and then use addremove, but forget -s? I actually forgot that
> addremove doesn't do renames by default (and you can't see the
> difference from status), so I think making -s100 the default is
> exactly right.

Ooh, summary should report the number of copies!

-- 
Mathematics is the supreme nostalgia of our time.