Re: blame follows renames, but log doesn't

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 20, 2007, 22:11 UTC
Message-ID: <f5c8mm$jaj$1@sea.gmane.org>
In-Reply-To: <4677A7EF.500@midwinter.com>

Steven Grimm wrote:

Show 19 quoted lines

> What git doesn't handle, but BitKeeper does, is applying directory 
> renames to newly created files. I rename the "lib" directory to "util", 
> you create a new file lib/strings.c and update lib/Makefile to compile 
> it. I pull from you. Under BitKeeper, I will get util/strings.c and the 
> change will be applied to my util/Makefile. git will create a brand-new 
> "lib" directory containing nothing but the new file, but since the 
> Makefile existed before, it will (correctly) apply your change to my 
> util/Makefile, which will then break my build because it will refer to a 
> file that doesn't exist in the Makefile's directory.
> 
> This has bitten me a few times in real life, e.g. in cases where I'm 
> importing a third-party source tarfile and reorganizing it a little to 
> fit it into my local build system. Every time they add a new source 
> file, I have to go manually clean up after it rather than just merging 
> the vendor branch into mine like I can do when they don't add anything. 
> It is not frequent enough to be a major hassle for me but it sure is 
> annoying when it happens (especially since sometimes the build *doesn't* 
> break and it takes a while to notice a newly created file isn't where it 
> should be.)

I think git can at least try to detect this situation, and perhaps even resolve this automatically. Namely, if we add file with the following <path>: <dirname>/<basename>, and <dirname> tree does exists in the ancestor but does not exist in the other branch, this is CONFLICT(add) (or something like that), with appropriate explanation.

One way to resolve this CONFLICT(add) automatically would be to check where all the files in no longer existing <dirname> moved to, and if they all are of the form <newdir>/<somename> then we should add the <dirname>/<basename> file under <newdir>/<basename>. If some of them were moved to other directory, for example contents of one directory got split into two directories, this is conflict which cannot be resolved automaticaly (CONFLICT(add/multiple) or something like that perhaps?). And I guess that SCM which _track_ renaming of directories, like Bazaar-NG, would NOT detect this as a conflict, and happily add to perhaps wrong directory.

Or we could reuse rename detection, taking modes+filenames as tree contents, or perhaps set of file contents as tree contents, for our content based rename detection.

P.S. Allow me to remind you rename _detection_ success story, send here some
time ago by Johannes Schindelin in the "Rename handling" thread:
  Message-ID: <Pine.LNX.4.63.0703210120230.22628@wbgn013.biozentrum.uni-wuerzburg.de>
  http://permalink.gmane.org/gmane.comp.version-control.git/42770

JS> By now, there have been enough arguments _for_ automatic rename detection, JS> but I'll add another one. JS> JS> A colleague of mine worked on a certain file in a branch, where he copied JS> the file to another location, and heavily modified it. He did that in a JS> branch, and when he was satisfied with the result, he deleted the old JS> file, since he liked the new location better. JS> JS> Now, when I pulled, imagine my surprise (knowing the history of the file), JS> when the pull reported a rename with a substantial similarity! JS> JS> So, the automatic renamer did an awesome job.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git