From: Ron Garret Date: Thu, 04 Feb 2010 00:10:38 GMT Subject: Re: git-mv redux: there must be something else going on Message-ID: In-Reply-To: <32541b131002031518t1017d351xcf9071f0a937474e@mail.gmail.com> In article <32541b131002031518t1017d351xcf9071f0a937474e@mail.gmail.com>, Avery Pennarun wrote: > On Wed, Feb 3, 2010 at 5:33 PM, Ron Garret wrote: > > 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. Makes sense. > 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 Thanks, that's a great read! rg