More aggressive tracking of renaming/copying?

[Gregory Szorc]

On Sat, Nov 23, 2019 at 7:00 AM Malcolm Matalka <mmatalka at gmail.com> wrote:

> I have a git repo that I use through hg-git, and this repo has a lot of
> copies and renames as well as changes.  using git diff -C -C -C ... it's
> quite nice for seeing how the files moved around the repo between
> revisions, but also seeing the diff after the move/copy.
>
> hg seems much less capable of tracking this and showing it to me.  I am
> using the --git option on diff but except for the most trivial examples,
> it seems to see it as a delete and an add, which makes seeing the "true"
> diff very challenging.  I have been resorting to git to review these
> changes.
>
> Are there some options I'm missing?  It seems like TortoiseHg might have
> such a way to change the similarity that diff sees as a copy but I'm not
> sure how it translates to the CLI?
>

Git computes copies/renames at run-time using an heuristic. Mercurial
stores copies/renames in changeset metadata and thus they must be recorded
at changeset creation time.

Tools like hg-git must therefore attempt to find copies/renames when
converting Git commits to Mercurial changesets.

By default, hg-git does not attempt to find copies/renames. You will need
to adjust at least the git.similarity config option to enable it. You may
also want to tweak the git.findcopiesharder and git.renamelimit options to
further tweak behavior. Please note that enabling copy/move detection can
be expensive - especially for git.findcopiesharder - and can slow down
conversion substantially.

While I'm here, you also may be interested in Mercurial's built-in automv
extension, which enables copy/rename annotations automatically at changeset
creation time. It will slow down certain operations. But usually the effect
is not noticeably unless your repository has tens of thousands of files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191123/33305de0/attachment-0002.html>