All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Roberto Tyley <roberto.tyley@gmail.com>
Cc: git@vger.kernel.org, jrnieder@gmail.com,
	Jeff King <peff@peff.net>,
	tr@thomasrast.ch
Subject: Re: [PATCH] docs: add filter-branch note about The BFG
Date: Tue, 17 Dec 2013 21:57:37 -0800	[thread overview]
Message-ID: <xmqqr49ak8fi.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAFY1edaEZzDUuG9kopbAp9h2Frc2aLRKkjKMUnpSonML2xZN=A@mail.gmail.com> (Roberto Tyley's message of "Wed, 18 Dec 2013 01:04:26 +0000")

Roberto Tyley <roberto.tyley@gmail.com> writes:

> * The BFG takes advantage of multi-core machines, cleaning commit
> file-trees in parallel, which git-filter-branch currently does not do.
> * Any particular version of a file is cleaned exactly _once_. The BFG,
> unlike git-filter-branch, does not give you the opportunity to handle
> a file differently based on where or when it was committed within your
> history.
> * The link:http://rtyley.github.io/bfg-repo-cleaner/#examples[command-set]
> is much more restrictive than git-filter branch, and dedicated just to
> the tasks of removing unwanted data - e.g. `--strip-blobs-bigger-than
> 1M`.

I do not know offhand if the above formats well with AsciiDoc.  You
may have to do it like this:

* The first line of the bulletted paragraph is
  followed by the second and subsequent lines indented
  to align with the first one.

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.

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.

  reply	other threads:[~2013-12-18  5:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17 10:53 [PATCH] docs: add filter-branch note about The BFG Roberto Tyley
2013-12-17 18:13 ` Junio C Hamano
2013-12-18  1:04   ` Roberto Tyley
2013-12-18  5:57     ` Junio C Hamano [this message]
2013-12-18 14:25       ` [PATCH v2] Tweaked notes on gfb<->bfg differences Roberto Tyley
2013-12-18 14:25         ` [PATCH v2] docs: add filter-branch notes on The BFG Roberto Tyley
2013-12-17 18:40 ` [PATCH] docs: add filter-branch note about " Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr49ak8fi.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=roberto.tyley@gmail.com \
    --cc=tr@thomasrast.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.