Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote: > The optimization broke the walk when all changes we adds, assuming > the parent was an empty tree. This assumption was wrong. The tree does > not have to bee empty, it can contain other trees and blobs. > > http://code.google.com/p/egit/issues/detail?id=46 > > Signed-off-by: Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> > --- > .../spearce/jgit/revwalk/RewriteTreeFilter.java | 7 ------- > 1 files changed, 0 insertions(+), 7 deletions(-) > > We could introduce a fixed version later on if we supply an option to select > whether to optimize the walk this way. The problem with doing it without an > option is that imports from legacy SCMs do not necessarily record file moves > as add/removes in direct sucession, but other events may happen in beteens > for various reasons. This is a fairly useful optimization in git. Most people use it, because most people don't pass "--full-history" when they run "git log -- path". So I think we really want to do it by default in jgit. Enabling this optimization again probably requires adding a new method to TreeFilter which allows the filter graph to return only nodes which select paths by name, and then do something like: else if (chgs == adds && isPathSetEmpty(c.getTree())) { c.parents = RevCommit.NO_PARENTS; return true; } where isPathSetEmpty runs a second TreeWalk iteration but uses the new (smaller) filter graph that only matches on paths. I'm not going to write that out today. But I thought I'd at least write an email while the idea was fresh in my head. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
