On 10 December 2014 at 16:05, Junio C Hamano <gits...@pobox.com> wrote: > Roberto Tyley <roberto.ty...@gmail.com> writes: > >> The BFG is generally faster than filter-branch for 3 reasons: >> >> 1. No forking - everything stays in the JVM process >> 2. Embarrassingly parallel algorithm makes good use of multi-core machines >> 3. Memoization means no Git object (file or folder) is cleaned more than once >> >> In the case of your problem, only the first factor will be noticeably >> helpful. Unfortunately commits do need to be cleaned sequentially, as >> their hashes depend on the hashes of their parents, and filter-branch >> doesn't clean /commits/ more than once, the way it does with files or >> folders - so the last 2 reasons in the list won't be significant. > > Just this part. If your history is bushy, you should be able to > rewrite histories of merged branches in parallel up to the point > they are merged---rewriting of the merge commit of course has to > wait until all the branches have been rewritten, though.
That's true, and the bfg does take advantage of that parallelism, so as well as point 1, point 2 will provide some benefit if history is bushy enough :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
