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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 3, 2010, 20:40 UTC
Message-ID: <32541b131002031240p6b67536ame6b69c6d662a7968@mail.gmail.com>
In-Reply-To: <ron1-34F9C6.12273203022010@news.gmane.org>

On Wed, Feb 3, 2010 at 3:27 PM, Ron Garret <ron1@flownet.com> wrote:

Show 5 quoted lines

> 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