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

[Avery Pennarun <apenwarr@gmail.com>]

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.)

Have fun,

Avery