In article <32541b131002031240p6b67536ame6b69c6d662a7968@xxxxxxxxxxxxxx>, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On Wed, Feb 3, 2010 at 3:27 PM, Ron Garret <ron1@xxxxxxxxxxx> 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.) 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. 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