The old description was misleading and logically impossible. It claimed that the ancestors of the original commit would be re-written to have the multiple emitted ids as parents. Not only would this modify existing objects, but it would create a cycle. What this actually does is pass the multiple emitted ids to the newly-created children to use as parents. Signed-off-by: Kevin Ballard <kevin@xxxxxx> --- Documentation/git-filter-branch.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 506c37a..541bf23 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -113,8 +113,8 @@ OPTIONS stdin. The commit id is expected on stdout. + As a special extension, the commit filter may emit multiple -commit ids; in that case, ancestors of the original commit will -have all of them as parents. +commit ids; in that case, the rewritten children of the original commit will +have all of them as parents. You probably don't want to do this. + You can use the 'map' convenience function in this filter, and other convenience functions, too. For example, calling 'skip_commit "$@"' -- 1.5.6.rc0.158.g7c7a1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
