[PATCH] add `hg guessrenames` extension

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Thu Jun 12 13:37:59 CDT 2008


On Thu, Jun 12, 2008 at 6:56 PM, Matt Mackall <mpm at selenic.com> wrote:
>
> On Thu, 2008-06-12 at 15:13 +0200, Peter Arrenbrecht wrote:
>> The background for this extension is that I very often either forget
>> to specify -s to `hg addrem` entirely, or only discover too late that
>> the similarity level wasn't quite right. (Yes, I know about -n, but I
>> usually forget it too.)
>>
>> Then I try to revert and that is a mess. And recently I lost work
>> because of such a revert --no-backup (yes, silly). So this extension
>> changes the workflow such that guessing renames is a separate, easily
>> repeatable operation.
>
> This is pretty much a losing proposition.
>
> Any time you have to explicitly mark data in an uncommon fashion for
> later use, you will invariably do it wrong more often than you do it
> right. That applies for file encodings, line endings, binary, and things
> like renames too. If I can forget to record a rename, I will, and I
> won't notice until I actually try to merge, by which time it's way too
> late to fix things up.
>
> So instead of putting more smarts into the check-in side of things, we
> should instead put more smarts into the merge side and teach it how to
> guess renames. It's better to guess on the merge side anyway, because we
> don't end up recording mere guesses as official history unless we're
> happy with the merge.

Ah, finally I see what you meant by "adding some smarts to copies.py" on IRC. :)

While I agree that some such mechanism would be very desirable (as
long as it remains under control), I beg to differ on the usefulness
of identifying renames upfront.

Firstly, I don't normally totally forget to record renames. If I did,
I would not have written guessrenames. Rather, the output of `hg
addrem` usually reminds me (just that little too late, but still early
enough) that I should record renames. So now I can simply use `hg
guessrenames` to fix things before I commit. And here's another
important point: While `guessrenames` guesses, I don't. I check its
output and correct the guesses. I do this at a point where I still
have a good idea of what was renamed to what - I'm just too lazy to
specify it manually, usually preferring to tweak similarity instead.

Secondly, I think rename information is not only useful for merges,
but also for interacting with other VCSes (svn, for instance). Having
to build these smarts into all of these commands, and keeping them
under control (meaning I get to review guesses if I so desire) does
not sound too attractive to me.

Thirdly, rename information might conceivably be used for truly cheap
copies in the store at some point. While this may not matter for the
smallish files typically given to findrenames, I think it still helps
to keep the story of recording renames manually a good one.

So again, I think adding smarts to copies.py to make merge more gitish
sounds good, but I don't think it invalidates the need for being able
to manage renames upfront comfortably.

-parren


More information about the Mercurial-devel mailing list