Detecting renames

Matt Mackall mpm at selenic.com
Sun Jun 6 15:07:22 CDT 2010


On Sun, 2010-06-06 at 21:00 +0200, Dirkjan Ochtman wrote:
> Apparently there's been a fuss at Mozilla because someone pushed some
> reorganization that used mv && addremove rather than hg mv (or mv &&
> hg mv -A). They are saying that there's a bug in rebase (in 1.2.1,
> which apparently someone was still using), do we know for sure that
> that bug has been fixed?

There's probably a bug in rebase.

What is up with Mozilla that we never seem to hear from them directly?

> After this happened, they tried to redo the cset and then do a merge,
> to try and make annotate handle it. Apparently, annotate doesn't do
> well with merges (which I think is another instance of the filelog not
> being a proper subgraph of the changelog). Can we get annotate an
> option to be slow and go through the changelog instead of the filelog?

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.

For now perhaps we should just make annotate slower unconditionally.

> Finally, IIRC addremove --similarity is now much faster than before.
> Can we make -s100 the default?

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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list