another perspective on renames.

Perhaps our thinking is being clouded by 'how other SCMs do things' --- do we *really* need extra rename metadata? As Linus pointed out, as long as a commit is done immediately after a rename (ie before the renamed file is changed) the tree object contains all the information one needs: you can notice that a given object's content-hash is named 'foo' in the first version and 'bar' in the second version.

Ingo thought that this was insufficient because two *different* objects (ie having different revision histories) might be mutated to a point where they had a *same* contents (and then would be condensed into a single blob). But isn't that a feature of the git-fs history generally (ie not a renaming-specific issue)?

One solution would be to invent a new 'file-revision-history' annotation on top of git-fs in order to keep these derivation paths seperate...

...but perhaps we might think of this as a 'feature' of our SCM instead? The 'history' of a file may have join points where a single 'content' may have been derived by two or more completely different paths. Explicit guidance to the front-end tools is required to 'unmerge' these files after this occurs (ie updating the directory cache for one, but not the others). This makes sense for include/arch/{foo,bar}/baz.h, but maybe not so much for (say) the empty file.

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.
  --scott

PBFORTUNE Soviet  cryptographic D5 SLBM MI5 CIA postcard WASHTUB [Hello to all my fans in domestic surveillance] 
explosion Sigint Bush ODEARL FJHOPEFUL assassination Uzi Hussein Nader
                          ( http://cscott.net/ )