Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- 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