Jakub Narebski wrote: > Petr Baudis wrote: >> If you use persistent file ids, you never miss it _AND_ you DO NOT WALK >> THE COMMIT CHAIN! You still just match file ids in the two trees. > > Let not jump to the one of the possible solution. The detecting and noting > renames and content moving (with user interaction) at commit is nice... > unless does something which cannot allow interactiveness (like applying > patchbomb), but even then detecting and saving info at commit would be > good idea. > > What we need is to for two given linked revisions (with a path between > them) to easily extract information about renames (content moving). > Perhaps using additional structure... best if we could do this without > walking the chain. The rest is details... ;-P Or rather structure, which for given file F in given revision A, for given other revision B would tell ALL the files in the revision B which are source of contents (via history/commit tree) of the file F. -- Jakub Narebski Warsaw, Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat May 06 23:38:33 2006
This archive was generated by hypermail 2.1.8 : 2006-05-06 23:38:53 EST