Re: git-mv redux: there must be something else going on
In article
<32541b131002031518t1017d351xcf9071f0a937474e@mail.gmail.com>,
Avery Pennarun <apenwarr@gmail.com> wrote:
Show 15 quoted lines
> On Wed, Feb 3, 2010 at 5:33 PM, Ron Garret <ron1@flownet.com> 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.
Show 7 quoted lines
> 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