Re: blame follows renames, but log doesn't

[Jakub Narebski <jnareb@gmail.com>]

Steven Grimm wrote:

> 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