In article <32541b131002031518t1017d351xcf9071f0a937474e@xxxxxxxxxxxxxx>, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On Wed, Feb 3, 2010 at 5:33 PM, Ron Garret <ron1@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html