On 18 December 2013 05:57, Junio C Hamano <gits...@pobox.com> 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(-)

-- (Apple Git-47)

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

Reply via email to