On 18 December 2013 05:57, Junio C Hamano <gitster@xxxxxxxxx> wrote: > The first bullet point may be somewhat misleading, though. Nothing > stops your script you use in filter-branch from processing blobs > belonging to a single tree in parallel---the user just needs to do a > bit more work to do so. Thanks, I've moved this entry down and clarified the capabilities - I think there's quite a big difference to the user (of a multi-core machine) as to whether parallelism happens by default, or whether they have to work out how to introduce it into the operation they're trying to perform. > I think the second point is the most characteristic in BFG (and that > is what allows easy parallelization of the filtering). Also, it > cannot be stressed enough that the "removing unwanted contents" use > case can take advantage of the "bad contents in a blob is bad, no > matter where in the tree and when in the history the blob appears". > That is what makes BFG particularly shine for the use case. Its > design very much aligns the objective the use case wants to achieve. I've moved this up to the first bullet-point and added text emphasising the significance the constraint plays in making the BFG work quickly while satisfying the common use-case. Roberto Tyley (1): docs: add filter-branch notes on The BFG Documentation/git-filter-branch.txt | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) -- 1.8.3.4 (Apple Git-47) -- 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