Re: Rename handling

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Mar 19, 2007, 20:19 UTC
Message-ID: <46a038f90703191319y54251f63ldc6060ffbc89deea@mail.gmail.com>
In-Reply-To: <45FEEB0C.3080602@midwinter.com>

On 3/20/07, Steven Grimm <koreth@midwinter.com> wrote:

> However, "Should we keep the existing rename detection?" is not the same
> question as, "Should the user be able to tell the system he's renaming
> something?"

How is a $SCM-mv that remembers useful in any _interesting_ scenario? You don't move it just because, you refactor and re-architect something.

In that area, git's mergers still have a bit to go -- I do hope for a day when I can say git-merge -s refactor or just git-merge -s tryharder so that it if hunks don't apply, git will try and trace where the block of code the hunk applies to has gone.

So recording mv doesn't solve anything other than 1% of the cases -- those full file moves that git will discover anyway even if the file changed a bit. And recording the mv gives you a false sense of being useful. It's not.

There's more work in having go-slow-and-really-try-to-merge-across-a-refactor mergers that could at least hint at where the hunk is likely to belong now.

> Until someone comes up with a way to make content-based rename detection
> 100% foolproof in the face of things like frequent self-references

Well, if code changes, there are no guarantees. Patching is a best-effort-but-not-too-smart thing. But in the end, a human needs to look at it if it's tricky. Wiggle users know ;-)

And, at the end of the day, hitting programmers that move sh*t around needlessly in the head works too. You wouldn't let them change projectwide function/method name conventions willy nilly either.

cheers,

martin