On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
After the discussions lately regarding the gcc svn mirror. I'm coming
up with a recipe to set up your own git-svn mirror. Suggestions on
the
following.
// Create directory and initialize git
mkdir gcc
cd gcc
git init
// add the remote site that currently mirrors gcc
// I have chosen the name gcc.gnu.org *1* as my local name to refer to
// this choose something else if you like
git remote add gcc.gnu.org git://git.infradead.org/gcc.git
// fetching someone else's remote branches is not a standard thing
to do
// so we'll need to edit our .git/config file
// you should have a section that looks like:
[remote "gcc.gnu.org"]
url = git://git.infradead.org/gcc.git
fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
// infradead's mirror puts the gcc svn branches in its own namespace
// refs/remotes/gcc.gnu.org/*
// change our fetch line accordingly
[remote "gcc.gnu.org"]
url = git://git.infradead.org/gcc.git
fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
// fetch the remote data from the mirror site
git remote update
With git version 1.5.3.6 on Mac OS X, this results in:
potomac%:~/gcc%git remote update
Updating gcc.gnu.org
/opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too
long
warning: no common commits
[after a long wait and a good amount of network traffic]
fatal: index-pack died of signal 13
fetch gcc.gnu.org: command returned error: 126
potomac%:~/gcc%
Any ideas on what to do to resolve this?
Hi,
On Mon, 17 Dec 2007, Geert Bosch wrote:
On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
quoted
After the discussions lately regarding the gcc svn mirror. I'm coming
up with a recipe to set up your own git-svn mirror. Suggestions on the
following.
// Create directory and initialize git
mkdir gcc
cd gcc
git init
// add the remote site that currently mirrors gcc
// I have chosen the name gcc.gnu.org *1* as my local name to refer to
// this choose something else if you like
git remote add gcc.gnu.org git://git.infradead.org/gcc.git
// fetching someone else's remote branches is not a standard thing to do
// so we'll need to edit our .git/config file
// you should have a section that looks like:
[remote "gcc.gnu.org"]
url = git://git.infradead.org/gcc.git
fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
// infradead's mirror puts the gcc svn branches in its own namespace
// refs/remotes/gcc.gnu.org/*
// change our fetch line accordingly
[remote "gcc.gnu.org"]
url = git://git.infradead.org/gcc.git
fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
// fetch the remote data from the mirror site
git remote update
With git version 1.5.3.6 on Mac OS X, this results in:
potomac%:~/gcc%git remote update
Updating gcc.gnu.org
/opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
warning: no common commits
[after a long wait and a good amount of network traffic]
fatal: index-pack died of signal 13
fetch gcc.gnu.org: command returned error: 126
potomac%:~/gcc%
Any ideas on what to do to resolve this?
Unfortunately, the builtin remote did not make it into git's master yet,
and it will probably miss 1.5.4.
Chances are that this would make the bug go away, but Junio said that on
one of his machines, the regression tests fail with the builtin remote.
In the meantime, "git fetch gcc.gnu.org" should do what you want,
methinks.
Hth,
Dscho
On Mon, 17 Dec 2007, Geert Bosch wrote:
With git version 1.5.3.6 on Mac OS X, this results in:
potomac%:~/gcc%git remote update
Updating gcc.gnu.org
/opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too long
Oops.
Any ideas on what to do to resolve this?
Can you try the current git tree? "git fetch" is built-in these days, and
that old shell-script that ran "git fetch--tool" on all the refs is no
more, so most likely the problem simply no longer exists.
But maybe there is some way to raise the argument size limit on OS X. One
thing to check is whether maybe you have an excessively big environment
(just run "printenv" to see what it contains) which might be cutting down
on the size allowed for arguments.
Linus