Re: git mirror at gcc.gnu.org

[Bernie Innocenti <bernie at codewiz dot org>]

On 06/10/09 02:43, Ian Lance Taylor wrote:
> fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware.
> That is now the one you will get if you connect to port "git".  Hope
> nothing breaks.

Thanks.

I made a few changes that hopefully won't compromise existing clones:

0) Since when Daniel disabled his cron job to update the repository,
   mine had not actually been running because the crontab line was
   commented out.  I enabled it.

1) Set UseDeltaBaseOffset=true for slightly smaller packs
   The downside is that we loose compatibility with git versions
   older than 1.4.4.  Moreover, people fetching from dumb protocols
   will probably have to refetch from scratch.

2) Remove the local checkout and configure the repository as
   "bare=true"

3) I stupidly ran a "git gc" on the repository without specifying
   any parameters, which made the pack jump to a whopping 3.4GB.
   People fetching over git-aware protocols shouldn't notice
   anything unusual except, maybe, longer server-side packing time.
   Those stuck with http:// will have a bad surprise. /me ducks.
   I've now configured the default window and depth both to 100,
   and ran another repack from scratch which will take a long,
   long, long, long time.

4) I noticed we weren't actually doing "git update-server-info"
   anywhere, which means that those stuck with http:// are
   probably unable to be annoyed by my careless mistake anyway.
   I've now added it as the last step of my cron job
   ~bernie/bin/git-update-toolchain.sh

5) The repository was configured with HEAD pointing at the local branch
   "master", which git-svn doesn't know (or care) about.  To make
   changes appear there too, Daniel's update script did a "git rebase"
   after every fetch, which does not work in bare repositories.
   Now I made HEAD point at branch "trunk" instead, and make "trunk"
   just be an indirect ref for "remotes/trunk", which is what git-svn
   actually updates. Hopefully this change won't break existing
   checkouts, but one might still have to perform some manual trickery
   to rename their local branch "master" to "trunk", or map it to
   remotes/trunk in their fetch configuration.

6) As Daniel said, we are indeed already mirroring all branches from
   the SVN repository.  But those go to remotes/foo rather than foo,
   which most likely *your* git fetches aren't configured to consider.
   And gitweb doesn't show them either.  As a workaround, I manually
   added a few local branches pointing directly to the remote ones.
   I arbitrarily chose to export all those gcc-4_x-branch tags, but
   we could add them all with a script, and maybe rename them to
   cull that "-branch" postfix which has been quite redundant since
   when we switched to svn.

I sincerely apologize if these changes happen to hamper someone's
productivity for a while.  Cheer up!  Your temporary suffering is
for the long-term good! :-)

Local to remote branch mapping is one of the least understood design
aspects in git [*], and probably the steepest point of git's steep
learning curve.  It is especially unfortunate that git-svn exposes
it even more than usual.

[*] the git haters would simply call it "lack of design in git"

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/