Re: another perspective on renames.

From: Ingo Molnar <mingo@elte.hu>
Date: Apr 15, 2005, 08:27 UTC
Message-ID: <20050415082759.GA26112@elte.hu>
In-Reply-To: <20050414221626.10c6c0e7.pj@engr.sgi.com>

* Paul Jackson <pj@engr.sgi.com> wrote:

Show 17 quoted lines

> Scott wrote:
> > Anyway, maybe it's worth thinking a little about an SCM in which this is a 
> > feature, instead of (or in addition to) automatically assuming this is a 
> > bug we need to add infrastructure to work around.
> 
> Agreed.
> 
> To me, the main purpose in tracking renames is to obtain a deeper
> history of the line-by-line changes in a file.
> 
>   ==> But that doesn't seem relevant here.
> 
> Last I looked, git has no such history.  A given file contents is the 
> indivisable atom of the git world, with no fine structure.
> 
> This is quite unlike classic SCM's, built on file formats that track 
> source lines, not files, as the atomic unit.

i believe the fundamental thing to think about is not file or line or namespace, but 'tracking developer intent'. While keeping in mind that GIT is not an SCM, all SCMs boil down to this single thing: being able to track what the developer did and why he did it - to be a useful tool later on. (SCMs are for humans with bad limitations, who have this fundamental design bug and keep forgetting things.)

the basic question is, how much to track. The most extreme form of tracking (just for the sake of visualizing it) would be to have an eye-position recognizing software attached to a webcam looking at the developer, and then exactly mapping what he did, how long did he look at one particular line of code and exactly what did he type when doing that. [ Perhaps also a thought-reader module in addition, once one is available. (combined with another module that removes all the swearing)]

but i think Linus is on the right track to suggest that "the file names dont matter all that much, it's all about the content". Global diffs might track most types of plain renames, and if it gets it wrong - do we care? Misdetection of renames can happen, but realistically only with small files and trivial code, which wont have alot of history.

The only serious type of misdetection would be if two large modules in two different places in the namespace happen to have exactly the same content but have a different history (because e.g. they were merged in via two separate trees, one came from one tree, the other from the other tree), and the developer renamed both of them in the same commit: in such a case the global diff would have no way to figure out what the proper thread of history is. But is this a realistic scenario? If the two files are nontrivial and have the same content, why werent they merged in the namespace in the first place?

the moment we allow 'namespace' into the picture, things get complex and ugly. Directory recursion is already a complexity that would have been nice to avoid.

	Ingo