Re: [Gnu-arch-users] Maintainership, and whiners...

[Bruce Stephens]

Martin Langhoff <address@hidden> writes:

[...]

> The problem with "expecting the scm to deal with renames" is that
> most SCMs have a very naive implementation, trying to catch renames
> and similar operations at _commit_ time. That's putting the smarts
> in the wrong place.

I think you're confusing two aspects.  Some SCMs try to guess renames,
but most don't.  In Mercurial, I can say "hg rename", and it doesn't
need to guess anything.  

There's complexity if you also want to support copy (as subversion
seems to, for example).  In that case it's tempting to regard rename
as copy+delete, but I'm not sure that that all works out right
semantically.

Rename on its own seems a relatively coherent notion, though?  It
seems like information that users can sensibly give an SCM, and that
an SCM can make use of.  If git (or any other system) doesn't *record*
renames, then that feels like a mistake; I can completely understand
why git might not attempt to use renames in any way (leaving that to
cogito or other front-ends).

[...]

>  + one of those merges deals with renames: if a target file in the
> patch isn't there, it walks up the commit history trying to find the
> commit where we last saw a file with that name, and then analyses
> that particular commit to detect the rename

Right, and *that* sounds like it's trying to be too smart.  

Depends how it gets patches, I guess.  If you need to receive raw
patches which don't explicitly indicate renames, then it's good to try
inferring them.  That seems like an important usage for most people.
But for projects working largely within a system, that feels
unnecessarily like guesswork.