Lee Carver <Lee.Carver@xxxxxxxxxxxxxx> writes: > As noted in several forums, a recommended way to move trees between > repositories > is to use git-filter-branch to revise the history for a single tree: > > http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth > er-preserving-history/ > http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-r > epo-to-another-not-a-clone-preserving-history > > However, this can lead to argument list too long errors when the original > repository has many retained branches (>6k) > > /usr/local/git/libexec/git-core/git-filter-branch: line 270: > /usr/local/git/libexec/git-core/git: Argument list too long > Could not get the commits > > Piping the saved output from git rev-parse into git rev-list avoids this > problem, since the rev-parse output is not processed as a command line > argument. > --- > git-filter-branch.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/git-filter-branch.sh b/git-filter-branch.sh > index ac2a005..2091885 100755 > --- a/git-filter-branch.shgit > +++ b/git-filter-branch.sh > @@ -255,7 +255,7 @@ else > remap_to_ancestor=t > fi > > -rev_args=$(git rev-parse --revs-only "$@") > +git rev-parse --revs-only "$@" > ../parse Where is this "rev-parse" command running? Is it always safe to clobber the file "../parse" like this? > > case "$filter_subdir" in > "") > @@ -268,7 +268,7 @@ case "$filter_subdir" in > esac > > git rev-list --reverse --topo-order --default HEAD \ > - --parents --simplify-merges $rev_args "$@" > ../revs || > + --parents --simplify-merges --stdin "$@" < ../parse > ../revs || > die "Could not get the commits" > commits=$(wc -l <../revs | tr -d " ") -- 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