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/
