Re: [EGIT PATCH] Avoid breaking the walk prematurely

From: Shawn O. Pearce <spearce@spearce.org>
Date: Nov 25, 2008, 00:12 UTC
Message-ID: <20081125001201.GH2932@spearce.org>
In-Reply-To: <1227570348-20092-1-git-send-email-robin.rosenberg@dewire.com>

Robin Rosenberg <robin.rosenberg@dewire.com> wrote:

Show 16 quoted lines

> 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@dewire.com>
> ---
>  .../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.