Duy Nguyen <[email protected]> writes: > The problem with indexing notes tree by blob is how the user will > manage it.
I do not think they have to be incompatible goals. Allowing the user to specify "at this commit, this path was moved to that path" may be a good thing. But at the same time, using a better data structure at runtime is also important. Unless I am reading your "cache" code wrong, it is always reading a flat list of unsorted "<blob> to <blob>" entries describing everything that happened in the entire history of the project into core, and then forcing the low-level code to find the entries relevant to the change in the commit it is looking at at runtime. The way the "cache" code stores and forces the runtime to use the data makes it proportional to the size of the history of the project (here I am assuming uniform "rename density" across history, the longer the history of a project, the more renames there would be) to find the manually defined renames just to show a single change, no? What was disappointing is that the way the rename notes is used during 'log -M' traversal is an example of a good design. When showing a single commit, the cost the code pays to get to the data for a single commit out of the rename notes tree does not grow proportional to the size of the history. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
