Re: git-mv redux: there must be something else going on

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 3, 2010, 23:18 UTC
Message-ID: <32541b131002031518t1017d351xcf9071f0a937474e@mail.gmail.com>
In-Reply-To: <ron1-9FA846.14332803022010@news.gmane.org>

On Wed, Feb 3, 2010 at 5:33 PM, Ron Garret <ron1@flownet.com> wrote:

Show 9 quoted lines

> 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