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
> 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(-)
18.104.22.168 (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