another perspective on renames.

["C. Scott Ananian" <cscott@cscott.net>]

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/ )