Re: Rename handling

["Martin Langhoff" <martin.langhoff@gmail.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