On Wed, Feb 3, 2010 at 5:33 PM, Ron Garret <ron1@flownet.com> wrote:
quoted text
> Here's a realistic case where keeping explicit track of renames could be
> useful.
>
> A and B start with a file named config.  A and B both make edits.  In
> addition, B renames config to be config1 and creates a new, very similar
> file called config2.  B then merges from A with the expectation that B's
> edits to config would end up in config1 and not config2.  It seems to me
> that without tracking renames, it would be luck of the draw which file
> the patch got applied to.

The problem is that this single "realistic case" is not actually very
common, and it's dwarfed by the other realistic cases: developer
forgets to use 'git mv' to rename the file; developer accidentally
deletes a file, commits, and then readds it later; etc.

Have I been bitten by exactly your example?  Yup.  But I've been
bitten by lots of other related things too, and explicit rename
tracking (at least in svn) has quite frequently made the problems
*worse*.  In my personal experience, git screws up less often.  The
fact that it's also elegant is a nice bonus too :)

More about this: http://marc.info/?l=git&m=114123702826251

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html