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

> On Wed, Feb 3, 2010 at 3:27 PM, Ron Garret <ron1@flownet.com> wrote:
> > So I think I'm beginning to understand how this works, but that leads me
> > to another question: it seems to me that there are potential screw cases
> > for this purely content-based system of tracking files.  For example,
> > suppose I have a directory full of sample config files, all of which are
> > similar to each other.  Will that cause diffcore to get confused?
> 
> Cases like that are always confusing, even to humans.  Person A
> renames X to Y, but at the same time creates Z which is almost
> identical.  Person B patches X, then merges in person A's changes.
> 
> What do you expect to happen?  Should Y be changed, because that's the
> file X was moved from?  Or should we change Z, because it's almost the
> same content anyway?  Or maybe we should change both, since a change
> to the old X is probably intended to affect the copied *content* that
> ended up in both Y and Z?
> 
> Simply storing whether person A has renamed vs. copied vs. added a
> file makes the answer to the "what do you expect to happen" question
> more obvious, but fails to answer the "what *should* happen" question.
>  Thus it's more of a distraction than a feature.  It took a while for
> me to accept this, but once I did, I realized that git's behaviour has
> still never caused me a problem in real life, despite repeated file
> renames and complicated merges.
> 
> In contrast, svn's explicit rename tracking has shot me in the foot
> numerous times.  (svn remembers when I delete file X and then
> subsequently re-add it with the same content.  So if I merge in
> someone's change to the *old* file X, it barfs because omg omg that's
> a totally different file X and it can't possibly figure out what to
> do.  Gee, thanks.  It's also hopelessly incompetent at handling
> "renames" in which a newbie developer didn't know to use svn mv, but
> instead used svn rm, mv, and svn add.)