Commit Graph

94 Commits

Author SHA1 Message Date
Christian Couder 3e0a5dc9af filter-branch doc: fix filter-repo typo
The name of the tool is 'git-filter-repo' not

Signed-off-by: Christian Couder <>
Reviewed-by: Elijah Newren <>
Signed-off-by: Junio C Hamano <>
2020-10-20 12:22:25 -07:00
Martin Ågren e469afe158 git-filter-branch.txt: wrap "maths" notation in backticks
In this paragraph, we have a few instances of the '^' character, which
we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor
renders it literally as "\^". Dropping the backslashes renders fine
with Asciidoctor, but not AsciiDoc...

An earlier version of this patch used "{caret}" instead of "^", which
avoided these escaping problems. The rendering was still so-so, though
-- these expressions end up set as normal text, similarly to when one
provides, e.g., computer code in the middle of running text, without
properly marking it with `backticks` to be monospaced.

As noted by Jeff King, this suggests actually wrapping these
expressions in backticks, setting them in monospace.

The lone "5" could be left as is or wrapped as `5`. Spell it out as
"five" instead -- this generally looks better anyway for small numbers
in the middle of text like this.

Suggested-by: Jeff King <>
Signed-off-by: Martin Ågren <>
Signed-off-by: Junio C Hamano <>
2020-02-04 12:17:18 -08:00
Junio C Hamano dfee504bee Merge branch 'ja/doc-markup-cleanup'
Doc cleanup.

* ja/doc-markup-cleanup:
  doc: indent multi-line items in list
  doc: remove non pure ASCII characters
2019-12-25 11:22:00 -08:00
Jean-Noël Avila df5be01669 doc: indent multi-line items in list
Although Asciidoc allows to not indent following lines in a list item,
it is clearer and safer to follow the recommended rule.

Signed-off-by: Jean-Noël Avila <>
Signed-off-by: Junio C Hamano <>
2019-12-13 12:18:07 -08:00
Junio C Hamano d3096d2ba6 Merge branch 'en/doc-typofix'

* en/doc-typofix:
  Fix spelling errors in no-longer-updated-from-upstream modules
  multimail: fix a few simple spelling errors
  sha1dc: fix trivial comment spelling error
  Fix spelling errors in test commands
  Fix spelling errors in messages shown to users
  Fix spelling errors in names of tests
  Fix spelling errors in comments of testcases
  Fix spelling errors in code comments
  Fix spelling errors in documentation outside of Documentation/
  Documentation: fix a bunch of typos, both old and new
2019-12-01 09:04:35 -08:00
Elijah Newren a6d39f2efb git-filter-branch.txt: correct argument name typo
Signed-off-by: Elijah Newren <>
Signed-off-by: Junio C Hamano <>
2019-11-07 14:40:47 +09:00
Elijah Newren 031fd4b93b Documentation: fix a bunch of typos, both old and new
Reported-by: Jens Schleusener <>
Signed-off-by: Elijah Newren <>
Signed-off-by: Junio C Hamano <>
2019-11-07 13:42:00 +09:00
Elijah Newren 9df53c5de6 Recommend git-filter-repo instead of git-filter-branch
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes).  Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use.  This can result in problems ranging from an
even messier history than what led folks to filter-branch in the first
place, to data loss or corruption.  These issues cannot be backward
compatibly fixed, so add a warning to both filter-branch and its manpage
recommending that another tool (such as filter-repo) be used instead.

Also, update other manpages that referenced filter-branch.  Several of
these needed updates even if we could continue recommending
filter-branch, either due to implying that something was unique to
filter-branch when it applied more generally to all history rewriting
tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because
something about filter-branch was used as an example despite other more
commonly known examples now existing.  Reword these sections to fix
these issues and to avoid recommending filter-branch.

Finally, remove the section explaining BFG Repo Cleaner as an
alternative to filter-branch.  I feel somewhat bad about this,
especially since I feel like I learned so much from BFG that I put to
good use in filter-repo (which is much more than I can say for
filter-branch), but keeping that section presented a few problems:
  * In order to recommend that people quit using filter-branch, we need
    to provide them a recomendation for something else to use that
    can handle all the same types of rewrites.  To my knowledge,
    filter-repo is the only such tool.  So it needs to be mentioned.
  * I don't want to give conflicting recommendations to users
  * If we recommend two tools, we shouldn't expect users to learn both
    and pick which one to use; we should explain which problems one
    can solve that the other can't or when one is much faster than
    the other.
  * BFG and filter-repo have similar performance
  * All filtering types that BFG can do, filter-repo can also do.  In
    fact, filter-repo comes with a reimplementation of BFG named
    bfg-ish which provides the same user-interface as BFG but with
    several bugfixes and new features that are hard to implement in
    BFG due to its technical underpinnings.
While I could still mention both tools, it seems like I would need to
provide some kind of comparison and I would ultimately just say that
filter-repo can do everything BFG can, so ultimately it seems that it
is just better to remove that section altogether.

Signed-off-by: Elijah Newren <>
Signed-off-by: Junio C Hamano <>
2019-09-05 13:01:48 -07:00
Corentin BOMPARD 68ed71b53c doc: format pathnames and URLs as monospace.
Applying CodingGuidelines about monospace on pathnames and URLs.

See Documentation/CodingGuidelines.txt for more information.

Signed-off-by: Corentin BOMPARD <>
Signed-off-by: Nathan BERBEZIER <>
Signed-off-by: Pablo CHABANNE <>
Signed-off-by: Matthieu MOY <>
Signed-off-by: Junio C Hamano <>
2019-03-13 11:14:22 +09:00
Junio C Hamano 6b0f1d9c47 Merge branch 'nd/doc-header'
Doc formatting fix.

* nd/doc-header:
  doc: keep first level section header in upper case
2018-05-23 14:38:22 +09:00
Nguyễn Thái Ngọc Duy 76a8788c14 doc: keep first level section header in upper case
When formatted as a man page, 1st section header is always in upper
case even if we write it otherwise. Make all 1st section headers
uppercase to keep it close to the final output.

This does affect html since case is kept there, but I still think it's
a good idea to maintain a consistent style for 1st section headers.

Some sections perhaps should become second sections instead, where
case is kept, and for better organization. I will update if anyone has
suggestions about this.

While at there I also make some header more consistent (e.g. examples
vs example) and fix a couple minor things here and there.

Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
2018-05-02 17:03:33 +09:00
Johannes Schindelin e2d65c1ea8 filter-branch: stop suggesting to use grafts
The graft file is deprecated now, so let's use replace refs in the example
in filter-branch's man page instead.

Suggested-by: Eric Sunshine <>
Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
2018-04-30 11:12:31 +09:00
Michele Locati 0a0eb2e585 filter-branch: return 2 when nothing to rewrite
Using the --state-branch option allows us to perform incremental filtering.
This may lead to having nothing to rewrite in subsequent filtering, so we need
a way to recognize this case.
So, let's exit with 2 instead of 1 when this "error" occurs.

Signed-off-by: Michele Locati <>
Signed-off-by: Junio C Hamano <>
2018-03-15 10:41:51 -07:00
Junio C Hamano e336afdfb6 Merge branch 'dg/filter-branch-filter-order-doc'
Update the documentation for "git filter-branch" so that the filter
options are listed in the same order as they are applied, as
described in an earlier part of the doc.

* dg/filter-branch-filter-order-doc:
  doc: list filter-branch subdirectory-filter first
2017-10-19 14:45:45 +09:00
David Glasser 07c4984508 doc: list filter-branch subdirectory-filter first
The docs claim that filters are applied in the listed order, so
subdirectory-filter should come first.

For consistency, apply the same order to the SYNOPSIS and the script's usage, as
well as the switch while parsing arguments.

Add missing --prune-empty to the script's usage.

Signed-off-by: David Glasser <>
Signed-off-by: Junio C Hamano <>
2017-10-18 09:10:15 +09:00
Ian Campbell bd2c79fbfe filter-branch: stash away ref map in a branch
With "--state-branch=<branchname>" option, the mapping from old object names
and filtered ones in ./map/ directory is stashed away in the object database,
and the one from the previous run is read to populate the ./map/ directory,
allowing for incremental updates of large trees.

Signed-off-by: Ian Campbell <>
Signed-off-by: Junio C Hamano <>
2017-09-22 12:57:43 +09:00
Andreas Heiduk 3b117f7301 filter-branch: add `--setup` step
A `--setup` step in `git filter-branch` makes it much easier to
define the initial values of variables used in the real filters.
Also sourcing/defining utility functions here instead of
`--env-filter` improves performance and minimizes clogging the
output in case of errors.

Signed-off-by: Andreas Heiduk <>
Signed-off-by: Junio C Hamano <>
2017-06-12 09:44:54 -07:00
Junio C Hamano 5160b821e9 Merge branch 'ah/doc-filter-branch-export-env'

* ah/doc-filter-branch-export-env:
  doc: filter-branch does not require re-export of vars
2017-06-04 09:55:43 +09:00
Andreas Heiduk ba746ff9c9 doc: filter-branch does not require re-export of vars
The function `set_ident` in `filter-branch` exported the variables
GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007.
Therefore the filter scripts don't need to re-eport them again.

Signed-off-by: Andreas Heiduk <>
Reviewed-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
2017-05-29 08:53:38 +09:00
Devin J. Pohly a582a82d24 filter-branch: fix --prune-empty on parentless commits
Previously, the git_commit_non_empty_tree function would always pass any
commit with no parents to git-commit-tree, regardless of whether the
tree was nonempty.  The new commit would then be recorded in the
filter-branch revision map, and subsequent commits which leave the tree
untouched would be correctly filtered.

With this change, parentless commits with an empty tree are correctly
pruned, and an empty file is recorded in the revision map, signifying
that it was rewritten to "no commits."  This works naturally with the
parent mapping for subsequent commits.

Signed-off-by: Devin J. Pohly <>
Signed-off-by: Junio C Hamano <>
2017-03-03 12:43:37 -08:00
Matthieu Moy 04b125de7e doc: typeset '--' as literal
This was obtained with:

  perl -pi -e "s/'--'/\`--\`/g" *.txt

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-28 08:36:45 -07:00
Matthieu Moy bcf9626a71 doc: typeset long command-line options as literal
Similarly to the previous commit, use backquotes instead of
forward-quotes, for long options.

This was obtained with:

  perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt

and manual tweak to remove false positive in ascii-art (o'--o'--o' to
describe rewritten history).

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-28 08:36:45 -07:00
Matthieu Moy 23f8239bbe doc: typeset short command-line options as literal
It was common in our documentation to surround short option names with
forward quotes, which renders as italic in HTML. Instead, use backquotes
which renders as monospace. This is one more step toward conformance to

This was obtained with:

  perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-28 08:20:52 -07:00
Tom Russello 47d81b5c7a doc: more consistency in environment variables format
Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped
(italic type) environment variables which are followed by the word
"environment". It was obtained with:

perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).

Signed-off-by: Tom Russello <>
Signed-off-by: Erwan Mathoniere <>
Signed-off-by: Samuel Groot <>
Signed-off-by: Matthieu Moy <>
Reviewed-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-08 12:04:37 -07:00
Junio C Hamano 1cca17dfff Documentation: fix linkgit references
There are a handful of incorrect "linkgit:<page>[<section>]"
instances in our documentation set.

 * Some have an extra colon after "linkgit:"; fix them by removing
   the extra colon;

 * Some refer to a page outside the Git suite, namely curl(1); fix
   them by using the `curl(1)` that already appears on the same page
   for the same purpose of referring the readers to its manual page.

 * Some spell the name of the page incorrectly, e.g. "rev-list" when
   they mean "git-rev-list"; fix them.

 * Some list the manual section incorrectly; fix them to make sure
   they match what is at the top of the target of the link.

Signed-off-by: Junio C Hamano <>
2016-05-09 15:44:14 -07:00
Thomas Ackermann f745acb028 Documentation: typofixes
In addition to fixing trivial and obvious typos, be careful about
the following points:

 - Spell ASCII, URL and CRC in ALL CAPS;
 - Spell Linux as Capitalized;
 - Do not omit periods in "i.e." and "e.g.".

Signed-off-by: Thomas Ackermann <>
Signed-off-by: Junio C Hamano <>
2014-11-04 13:14:44 -08:00
Roberto Tyley 2df85669d1 Documentation: fix documentation AsciiDoc links for external urls
Turns out that putting 'link:' before the 'http' is actually superfluous
in AsciiDoc, as there's already a predefined macro to handle it.

"http, https, [etc] URLs are rendered using predefined inline macros."

"Hypertext links to files on the local file system are specified
using the link inline macro."

Despite being superfluous, the reference implementation of AsciiDoc
tolerates the extra 'link:' and silently removes it, giving a functioning
link in the generated HTML. However, AsciiDoctor (the Ruby implementation
of AsciiDoc used to render the site) does /not/ have
this behaviour, and so generates broken links, as can be seen here: (links to cvs2git & parsecvs) (link to The BFG)

It's worth noting that after this change, the html generated by 'make html'
in the git project is identical, and all links still work.

Signed-off-by: Roberto Tyley <>
Signed-off-by: Junio C Hamano <>
2014-02-20 14:14:58 -08:00
Roberto Tyley 615b8f1a8d docs: add filter-branch notes on The BFG
The BFG is a tool specifically designed for the task of removing
unwanted data from Git repository history - a common use-case for which
git-filter-branch has been the traditional workhorse.

It's beneficial to let users know that filter-branch has an alternative

* speed : The BFG is 10-50x faster
* complexity of configuration : filter-branch is a very flexible tool,
  but demands very careful usage in order to get the desired results

Obviously, filter-branch has it's advantages too - it permits very
complex rewrites, and doesn't require a JVM - but for the common
use-case of deleting unwanted data, it's helpful to users to be aware
that an alternative exists.

The BFG was released under the GPL in February 2013, and has since seen
widespread production use (The Guardian, RedHat, Google, UK Government
Digital Service), been tested against large repos (~300K commits, ~5GB
packfiles) and received significant positive feedback from users:

Signed-off-by: Roberto Tyley <>
Signed-off-by: Junio C Hamano <>
2013-12-18 10:41:41 -08:00
Junio C Hamano dbe71f9e24 Merge branch 'tk/doc-filter-branch'
* tk/doc-filter-branch:
  Documentation: filter-branch env-filter example
  git-filter-branch.txt: clarify ident variables usage
2013-03-19 12:20:50 -07:00
Tadeusz Andrzej Kadłubowski 21b6e4f24c Documentation: filter-branch env-filter example
filter-branch --env-filter example that shows how to change the email
address in all commits before publishing a project.

Signed-off-by: Tadeusz Andrzej Kadłubowski <>
Signed-off-by: Junio C Hamano <>
2013-02-26 09:34:51 -08:00
Tadeusz Andrzej Kadłubowski bee3eb079d git-filter-branch.txt: clarify ident variables usage
There is a rare edge case of git-filter-branch: a filter that unsets
identity variables from the environment. Link to git-commit-tree
clarifies how Git would fall back in this situation.

Signed-off-by: Tadeusz Andrzej Kadłubowski <>
Signed-off-by: Junio C Hamano <>
2013-02-26 09:34:51 -08:00
Thomas Ackermann 2de9b71138 Documentation: the name of the system is 'Git', not 'git'
Signed-off-by: Thomas Ackermann <>
Signed-off-by: Junio C Hamano <>
2013-02-01 13:53:33 -08:00
Andreas Schwab 8093ae8854 Documentation/git-filter-branch: Move note about effect of removing commits
The note that explains that changes introduced by removed commits are
preserved should be placed directly after the paragraph that describes
such commits removal.  Otherwise the reference to "the commits" appears
out of context.

Also the big example that follows "Consider this history" is about
rewriting part of the history DAG.  Move the paragraph that
describes the operation close to it.

Signed-off-by: Andreas Schwab <>
Signed-off-by: Junio C Hamano <>
2012-09-18 12:51:58 -07:00
Junio C Hamano 74b819aa31 Merge branch 'jc/tag-doc' into maint-1.7.11
Our documentation used to assume having files in .git/refs/*
directories was the only to have branches and tags, but that is not
true for quite some time.

* jc/tag-doc:
  Documentation: do not mention .git/refs/* directories
2012-08-24 12:05:30 -07:00
Junio C Hamano 831e61f80f Documentation: do not mention .git/refs/* directories
It is an implementation detail that a new tag is created by adding a
file in the .git/refs/tags directory.  The only thing the user needs
to know is that a "git tag" creates a ref in the refs/tags namespace,
and without "-f", it does not overwrite an existing tag.

Inspired by a report from 乙酸鋰 <>; I think I
caught all the existing mention in Documentation/ directory in the
tip of 1.7.9.X maintenance track, but we may have added new ones
since then.

Signed-off-by: Junio C Hamano <>
2012-08-06 14:04:16 -07:00
Jeff King 6cf378f0cb docs: stop using asciidoc no-inline-literal
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.

It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:

  1. The source is much easier to read when the literal
     contains punctuation. You can use `master~1` instead
     of `master{tilde}1`.

  2. They are less error-prone. Because of point (1), we
     tend to make mistakes and forget the extra layer of

This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the

Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:

  - HTML rendering used the ellipsis character instead of
    literal "..." in code examples (like "git log A...B")

  - some code examples used the right-arrow character
    instead of '->' because they failed to quote

  - api-config.txt did not quote tilde, and the resulting
    HTML contained a bogus snippet like:

      <tt><sub></tt> foo <tt></sub>bar</tt>

    which caused some parsers to choke and omit whole
    sections of the page.

  - git-commit.txt confused ``foo`` (backticks inside a
    literal) with ``foo'' (matched double-quotes)

  - mentions of `A U Thor <>` used to
    erroneously auto-generate a mailto footnote for

  - the description of --word-diff=plain incorrectly showed
    the output as "[-removed-] and {added}", not "{+added+}".

  - using "prime" notation like:

      commit `C` and its replacement `C'`

    confused asciidoc into thinking that everything between
    the first backtick and the final apostrophe were meant
    to be inside matched quotes

  - asciidoc got confused by the escaping of some of our
    asterisks. In particular,

      `credential.\*` and `credential.<url>.\*`

    properly escaped the asterisk in the first case, but
    literally passed through the backslash in the second

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
2012-04-26 13:19:06 -07:00
Peter Collingbourne 0dc310e860 Documentation: git-filter-branch honors replacement refs
Make it clear that git-filter-branch will honor and make permanent
replacement refs as well as grafts.

Signed-off-by: Peter Collingbourne <>
Signed-off-by: Junio C Hamano <>
2011-07-21 12:54:55 -07:00
Junio C Hamano 142c945e6e Merge branch 'maint'
* maint:
  docs: fix filter-branch subdir example for exotic repo names
2011-04-01 17:45:59 -07:00
Jeff King 6cb0186a41 docs: fix filter-branch subdir example for exotic repo names
The GIT_INDEX_FILE variable we get from git has the full
path to the repo, which may contain spaces. When we use it
in our shell snippet, it needs to be quoted.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
2011-04-01 12:17:45 -07:00
Jeff King 48bb914ed6 doc: drop author/documentation sections from most pages
The point of these sections is generally to:

  1. Give credit where it is due.

  2. Give the reader an idea of where to ask questions or
     file bug reports.

But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame.  For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody

So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.

Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
2011-03-11 10:59:16 -05:00
Štěpán Němec 0adda9362a Use parentheses and `...' where appropriate
Remove some stray usage of other bracket types and asterisks for the
same purpose.

Signed-off-by: Štěpán Němec <>
Acked-by: Jonathan Nieder <>
Signed-off-by: Junio C Hamano <>
2010-10-08 12:31:07 -07:00
Wesley J. Landaker 831a8b843b Documentation: Refer to git-commit-tree in git-filter-branch help
Currently, the help for git filter-branch refers users of --env-filter
to git-commit for information about environment variables affecting
commits. However, this information is not contained in the git-commit
help, but is very explicitly detailed in git-commit-tree.

Signed-off-by: Wesley J. Landaker <>
Signed-off-by: Junio C Hamano <>
2010-09-27 11:39:44 -07:00
Csaba Henk 7ec344d802 filter-branch: retire --remap-to-ancestor
We can be clever and know by ourselves when we need the behavior
implied by "--remap-to-ancestor". No need to encumber users by having
them exposed to it as a tunable. (Option kept for backward compatibility,
but it's now a no-op.)

Signed-off-by: Csaba Henk <>
Signed-off-by: Junio C Hamano <>
2010-08-27 16:47:01 -07:00
Jeff King d2d66f15b6 docs: fix filter-branch example for quoted paths
If there is a quoted path, update-index will correctly
unquote it. However, we must take care to put our new prefix
inside the double-quote.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
2010-02-06 10:52:14 -08:00
Thomas Rast 0b444cdb19 Documentation: spell 'git cmd' without dash throughout
The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.

The current trend goes towards dashless forms, and there is precedent
in 647ac70 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.

Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
2010-01-10 13:01:28 +01:00
Thomas Rast ca768288b6 Documentation: format full commands in typewriter font
Use `code snippet` style instead of 'emphasis' for `git cmd ...`
according to the following rules:

* The SYNOPSIS sections are left untouched.

* If the intent is that the user type the command exactly as given, it
  is `code`.
  If the user is only loosely referred to a command and/or option, it
  remains 'emphasised'.

Signed-off-by: Thomas Rast <>
2010-01-10 13:01:25 +01:00
Thomas Rast f2f3a6b802 filter-branch: nearest-ancestor rewriting outside subdir filter
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.

However, that rewriting strategy is also a useful building block in
other tasks.  For example, if you want to split out a subset of files
from your history, you would typically call

  git filter-branch -- <refs> -- <files>

But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.

The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.

Signed-off-by: Thomas Rast <>
Signed-off-by: Johannes Sixt <>
Signed-off-by: Junio C Hamano <>
2009-11-13 11:26:43 -08:00
Adam Brewster e3679ab4a8 filter-branch: add --prune-empty to option summary
Signed-off-by: Adam Brewster <>
Signed-off-by: Jeff King <>
2009-10-02 03:58:24 -04:00
Johannes Schindelin b8f423327b filter-branch: add an example how to add ACKs to a range of commits
When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your

It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.

Signed-off-by: Johannes Schindelin <>
Signed-off-by: Junio C Hamano <>
2009-08-18 12:20:58 -07:00
Junio C Hamano a54c4edc51 Merge branch 'maint'
* maint:
  State the effect of filter-branch on graft explicitly
  process_{tree,blob}: Remove useless xstrdup calls

2009-04-12 16:01:25 -07:00