From: Junio C Hamano Date: Fri, 15 Jul 2011 18:51:49 GMT Subject: Re: Strange O(N^3) behavior in "git filter-branch" Message-ID: <7vlivz1inu.fsf@alter.siamese.dyndns.org> In-Reply-To: <4E200611.9010005@alum.mit.edu> Michael Haggerty writes: > 1. Change git-filter-branch (and any other long-running commands?) to do > an initial check for the presence of replace references (packed or > loose), and if there are none, set GIT_NO_REPLACE_OBJECTS automatically. > This would of course fail if any of the user's scripts try to set up > replace references. (Side note: perhaps the git-replace command should > complain if GIT_NO_REPLACE_OBJECTS is turned on? It would almost always > indicate a mistake.) It also wouldn't help in repositories that *have* > replace references. In the short term I think this makes sense, as the whole point of using filter-branch in a repository that has grafts and replacements is so that the resulting history won't have to look-aside into grafts and replace information. But I think the replace-object codepath should be optimized to realize there is no funky replacement (which _is_ a rare configuration) going on much early so that it does not incur that much overhead you observed. IOW, I tend to agree with your 3. below. > 2. Add an option to git-filter-branch to have it pack references > occasionally. Doesn't the code already do this via "git gc" though? > 3. Optimize the specific case where there is no refs/replace > directory--if this directory is missing, then defer populating the loose > refs cache in the hope that it will never be needed.