filter-branch: fix remnants of old syntax in documentation
Some time ago, filter-branch's syntax changed so that more than one ref can be rewritten at the same time. This involved the removal of the ref name for the result; instead, the refs are rewritten in-place. This updates the last leftovers in the documentation to reflect the new behavior. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:

committed by
Junio C Hamano

parent
88e21dc746
commit
082036688f
@ -17,19 +17,19 @@ SYNOPSIS
|
|||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
Lets you rewrite git revision history by creating a new branch from
|
Lets you rewrite git revision history by rewriting the branches mentioned
|
||||||
your current branch, applying custom filters on each revision.
|
in the <rev-list options>, applying custom filters on each revision.
|
||||||
Those filters can modify each tree (e.g. removing a file or running
|
Those filters can modify each tree (e.g. removing a file or running
|
||||||
a perl rewrite on all files) or information about each commit.
|
a perl rewrite on all files) or information about each commit.
|
||||||
Otherwise, all information (including original commit times or merge
|
Otherwise, all information (including original commit times or merge
|
||||||
information) will be preserved.
|
information) will be preserved.
|
||||||
|
|
||||||
The command takes the new branch name as a mandatory argument and
|
The command will only rewrite the _positive_ refs mentioned in the
|
||||||
the filters as optional arguments. If you specify no filters, the
|
command line (i.e. if you pass 'a..b', only 'b' will be rewritten).
|
||||||
commits will be recommitted without any changes, which would normally
|
If you specify no filters, the commits will be recommitted without any
|
||||||
have no effect. Nevertheless, this may be useful in the future for
|
changes, which would normally have no effect. Nevertheless, this may be
|
||||||
compensating for some git bugs or such, therefore such a usage is
|
useful in the future for compensating for some git bugs or such,
|
||||||
permitted.
|
therefore such a usage is permitted.
|
||||||
|
|
||||||
*WARNING*! The rewritten history will have different object names for all
|
*WARNING*! The rewritten history will have different object names for all
|
||||||
the objects and will not converge with the original branch. You will not
|
the objects and will not converge with the original branch. You will not
|
||||||
@ -43,8 +43,8 @@ if different from the rewritten ones, will be stored in the namespace
|
|||||||
'refs/original/'.
|
'refs/original/'.
|
||||||
|
|
||||||
Note that since this operation is extensively I/O expensive, it might
|
Note that since this operation is extensively I/O expensive, it might
|
||||||
be a good idea to redirect the temporary directory off-disk, e.g. on
|
be a good idea to redirect the temporary directory off-disk with the
|
||||||
tmpfs. Reportedly the speedup is very noticeable.
|
'-d' option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
|
||||||
|
|
||||||
|
|
||||||
Filters
|
Filters
|
||||||
@ -112,6 +112,9 @@ OPTIONS
|
|||||||
As a special extension, the commit filter may emit multiple
|
As a special extension, the commit filter may emit multiple
|
||||||
commit ids; in that case, ancestors of the original commit will
|
commit ids; in that case, ancestors of the original commit will
|
||||||
have all of them as parents.
|
have all of them as parents.
|
||||||
|
+
|
||||||
|
Note that the 'map' function is not available in the commit filter yet.
|
||||||
|
This will be changed in a future version.
|
||||||
|
|
||||||
--tag-name-filter <command>::
|
--tag-name-filter <command>::
|
||||||
This is the filter for rewriting tag names. When passed,
|
This is the filter for rewriting tag names. When passed,
|
||||||
@ -186,8 +189,8 @@ order to paste the other history behind the current history:
|
|||||||
git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
|
git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
|
||||||
-------------------------------------------------------------------
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
(if the parent string is empty - therefore we are dealing with the
|
(if the parent string is empty - which happens when we are dealing with
|
||||||
initial commit - add graftcommit as a parent). Note that this assumes
|
the initial commit - add graftcommit as a parent). Note that this assumes
|
||||||
history with a single root (that is, no merge without common ancestors
|
history with a single root (that is, no merge without common ancestors
|
||||||
happened). If this is not the case, use:
|
happened). If this is not the case, use:
|
||||||
|
|
||||||
@ -232,11 +235,12 @@ range in addition to the new branch name. The new branch name will
|
|||||||
point to the top-most revision that a 'git rev-list' of this range
|
point to the top-most revision that a 'git rev-list' of this range
|
||||||
will print.
|
will print.
|
||||||
|
|
||||||
Note that the changes introduced by the commits, and not reverted by
|
*NOTE* the changes introduced by the commits, and which are not reverted
|
||||||
subsequent commits, will still be in the rewritten branch. If you want
|
by subsequent commits, will still be in the rewritten branch. If you want
|
||||||
to throw out _changes_ together with the commits, you should use the
|
to throw out _changes_ together with the commits, you should use the
|
||||||
interactive mode of gitlink:git-rebase[1].
|
interactive mode of gitlink:git-rebase[1].
|
||||||
|
|
||||||
|
|
||||||
Consider this history:
|
Consider this history:
|
||||||
|
|
||||||
------------------
|
------------------
|
||||||
|
Reference in New Issue
Block a user