* git mirror at infradead? @ 2009-06-07 5:22 Ralf Wildenhues 2009-06-07 10:18 ` Bernie Innocenti 0 siblings, 1 reply; 29+ messages in thread From: Ralf Wildenhues @ 2009-06-07 5:22 UTC (permalink / raw) To: bernie; +Cc: gcc Hello Bernardo, sorry if this is not an official mirror of the GCC tree, but <git://git.infradead.org/toolchain/gcc.git> has not been updated since June 1. Any chance you (or whoever is responsible) could look into it? Thanks! Ralf ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 5:22 git mirror at infradead? Ralf Wildenhues @ 2009-06-07 10:18 ` Bernie Innocenti 2009-06-07 10:40 ` Ralf Wildenhues 0 siblings, 1 reply; 29+ messages in thread From: Bernie Innocenti @ 2009-06-07 10:18 UTC (permalink / raw) To: Ralf Wildenhues, gcc; +Cc: Harvey Harrison, David Woodhouse On 06/07/09 07:21, Ralf Wildenhues wrote: > Hello Bernardo, > > sorry if this is not an official mirror of the GCC tree, but > <git://git.infradead.org/toolchain/gcc.git> has not been updated since > June 1. Any chance you (or whoever is responsible) could look into it? The git-svn process was stuck on a read(), with the socket to gcc.gnu.org still open. Killing the process and running the update script again fixed it. The same happened a few months ago. I'm not sure what triggers it, and whether git-svn or svnserve is to blame for it. I now made the cron job complain to me by email if it detects a stuck process, so I shall notice sooner, but thank you for reporting. BTW, we also have another up-to-date git mirror, supposedly the "official" one: http://gcc.gnu.org/git/?p=gcc.git I never got around to give it the necessary love, though, such as configuring a few more branches. Also, sourceware still running git 1.5 doesn't help (git-svn was greatly improved in git 1.6). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 10:18 ` Bernie Innocenti @ 2009-06-07 10:40 ` Ralf Wildenhues 2009-06-07 11:38 ` Bernie Innocenti 0 siblings, 1 reply; 29+ messages in thread From: Ralf Wildenhues @ 2009-06-07 10:40 UTC (permalink / raw) To: Bernie Innocenti; +Cc: gcc, Harvey Harrison, David Woodhouse Hello Bernie, * Bernie Innocenti wrote on Sun, Jun 07, 2009 at 12:17:44PM CEST: > On 06/07/09 07:21, Ralf Wildenhues wrote: > > sorry if this is not an official mirror of the GCC tree, but > > <git://git.infradead.org/toolchain/gcc.git> has not been updated since > > June 1. Any chance you (or whoever is responsible) could look into it? > > The git-svn process was stuck on a read(), with the socket to > gcc.gnu.org still open. Killing the process and running the update > script again fixed it. Thanks! > BTW, we also have another up-to-date git mirror, supposedly the > "official" one: > > http://gcc.gnu.org/git/?p=gcc.git Is this mirror an independent conversion from the infradead one (i.e., I have to throw away the repo and re-download a full repo? Or can I reuse objects)? > I never got around to give it the necessary love, though, such as > configuring a few more branches. Oh. Yes, at least the still-active release branches would be nice to have. > Also, sourceware still running git 1.5 > doesn't help (git-svn was greatly improved in git 1.6). Does that mean you would like to redo the full export after updating git-svn? If yes, then I'd want to wait until after that before switching. Thanks, Ralf ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 10:40 ` Ralf Wildenhues @ 2009-06-07 11:38 ` Bernie Innocenti 2009-06-07 12:08 ` Bernie Innocenti 2009-06-09 14:18 ` Jason Merrill 0 siblings, 2 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-07 11:38 UTC (permalink / raw) To: Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/07/09 12:40, Ralf Wildenhues wrote: > Is this mirror an independent conversion from the infradead one (i.e., I > have to throw away the repo and re-download a full repo? Or can I reuse > objects)? It's an independent mirror, and I wouldn't recommend switching to it yet. There are permissions problems, and I might end up rsyncing the whole infradead repository rather than fixing things locally. >> I never got around to give it the necessary love, though, such as >> configuring a few more branches. > > Oh. Yes, at least the still-active release branches would be nice to > have. There was a problem with git-svn creating very large temporary files for each branch or tag, but iirc it was solved in 1.6. > Does that mean you would like to redo the full export after updating > git-svn? If yes, then I'd want to wait until after that before > switching. Indeed. I could build git locally in my account, but I'd rather have a sourceware admin update git system-wise. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 11:38 ` Bernie Innocenti @ 2009-06-07 12:08 ` Bernie Innocenti 2009-06-07 21:55 ` Daniel Berlin 2009-06-09 14:18 ` Jason Merrill 1 sibling, 1 reply; 29+ messages in thread From: Bernie Innocenti @ 2009-06-07 12:08 UTC (permalink / raw) To: Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse, Daniel Berlin On 06/07/09 13:38, Bernie Innocenti wrote: > On 06/07/09 12:40, Ralf Wildenhues wrote: >> Is this mirror an independent conversion from the infradead one (i.e., I >> have to throw away the repo and re-download a full repo? Or can I reuse >> objects)? > > It's an independent mirror, and I wouldn't recommend switching to it yet. > > There are permissions problems, and I might end up rsyncing the whole > infradead repository rather than fixing things locally. Daniel, could you please execute these commands on sourceware? cd /sourceware/projects/gcc-home/gitfiles chmod g+w -R . find . -type d -print0 | xargs -0 chmod g+s Where is the cron job to update the mirror? Could you make it writable by group gcc, or just disable it so I can start mine from my user crontab? Thanks! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 12:08 ` Bernie Innocenti @ 2009-06-07 21:55 ` Daniel Berlin 0 siblings, 0 replies; 29+ messages in thread From: Daniel Berlin @ 2009-06-07 21:55 UTC (permalink / raw) To: Bernie Innocenti; +Cc: Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On Sun, Jun 7, 2009 at 8:08 AM, Bernie Innocenti<bernie@codewiz.org> wrote: > On 06/07/09 13:38, Bernie Innocenti wrote: >> On 06/07/09 12:40, Ralf Wildenhues wrote: >>> Is this mirror an independent conversion from the infradead one (i.e., I >>> have to throw away the repo and re-download a full repo? Or can I reuse >>> objects)? >> >> It's an independent mirror, and I wouldn't recommend switching to it yet. >> >> There are permissions problems, and I might end up rsyncing the whole >> infradead repository rather than fixing things locally. > > Daniel, could you please execute these commands on sourceware? > > cd /sourceware/projects/gcc-home/gitfiles > chmod g+w -R . > find . -type d -print0 | xargs -0 chmod g+s > Done. > Where is the cron job to update the mirror? Could you make it writable > by group gcc, or just disable it so I can start mine from my user crontab? I can't make it writable, but i have disabled it. > > Thanks! > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-07 11:38 ` Bernie Innocenti 2009-06-07 12:08 ` Bernie Innocenti @ 2009-06-09 14:18 ` Jason Merrill 2009-06-09 19:17 ` Bernie Innocenti 1 sibling, 1 reply; 29+ messages in thread From: Jason Merrill @ 2009-06-09 14:18 UTC (permalink / raw) To: Bernie Innocenti Cc: Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse, Daniel Berlin Bernie Innocenti wrote: > On 06/07/09 12:40, Ralf Wildenhues wrote: >> Is this mirror an independent conversion from the infradead one (i.e., I >> have to throw away the repo and re-download a full repo? Or can I reuse >> objects)? > > It's an independent mirror, and I wouldn't recommend switching to it yet. > > There are permissions problems, and I might end up rsyncing the whole > infradead repository rather than fixing things locally. Please please do *not* rsync the infradead repository. The repository on gcc.gnu.org is set up so that I can switch back and forth between pulling from git and using git-svn directly; the infradead repository is not. For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc, which makes it impossible to use git-svn to check in changes; the gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is right and proper. Also the remotes are in a different place from where git-svn puts them, though I suppose that's easy enough to adjust when fetching. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-09 14:18 ` Jason Merrill @ 2009-06-09 19:17 ` Bernie Innocenti 2009-06-10 0:12 ` Daniel Berlin 2009-06-11 1:38 ` git mirror at infradead? Jason Merrill 0 siblings, 2 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-09 19:17 UTC (permalink / raw) To: Jason Merrill Cc: Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse, Daniel Berlin On 06/09/09 16:17, Jason Merrill wrote: > Bernie Innocenti wrote: >> On 06/07/09 12:40, Ralf Wildenhues wrote: >>> Is this mirror an independent conversion from the infradead one (i.e., I >>> have to throw away the repo and re-download a full repo? Or can I reuse >>> objects)? >> >> It's an independent mirror, and I wouldn't recommend switching to it yet. >> >> There are permissions problems, and I might end up rsyncing the whole >> infradead repository rather than fixing things locally. > > Please please do *not* rsync the infradead repository. The repository > on gcc.gnu.org is set up so that I can switch back and forth between > pulling from git and using git-svn directly; the infradead repository is > not. > > For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc, > which makes it impossible to use git-svn to check in changes; the > gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is > right and proper. Also the remotes are in a different place from where > git-svn puts them, though I suppose that's easy enough to adjust when > fetching. I won't re-create the repository from scratch, then. Though I would still need an updated version of git to enable lots of branches and tags without wasting too much hard disk space. Can a sourceware admin please install (or build) git 1.6.3.x? If there are concerns of breaking other things, I could install a local copy in ~/bin. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-09 19:17 ` Bernie Innocenti @ 2009-06-10 0:12 ` Daniel Berlin 2009-06-10 0:43 ` Ian Lance Taylor 2009-06-11 1:38 ` git mirror at infradead? Jason Merrill 1 sibling, 1 reply; 29+ messages in thread From: Daniel Berlin @ 2009-06-10 0:12 UTC (permalink / raw) To: Bernie Innocenti, overseers Cc: Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On Tue, Jun 9, 2009 at 3:16 PM, Bernie Innocenti<bernie@codewiz.org> wrote: > On 06/09/09 16:17, Jason Merrill wrote: >> Bernie Innocenti wrote: >>> On 06/07/09 12:40, Ralf Wildenhues wrote: >>>> Is this mirror an independent conversion from the infradead one (i.e., I >>>> have to throw away the repo and re-download a full repo? Or can I reuse >>>> objects)? >>> >>> It's an independent mirror, and I wouldn't recommend switching to it yet. >>> >>> There are permissions problems, and I might end up rsyncing the whole >>> infradead repository rather than fixing things locally. >> >> Please please do *not* rsync the infradead repository. The repository >> on gcc.gnu.org is set up so that I can switch back and forth between >> pulling from git and using git-svn directly; the infradead repository is >> not. >> >> For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc, >> which makes it impossible to use git-svn to check in changes; the >> gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is >> right and proper. Also the remotes are in a different place from where >> git-svn puts them, though I suppose that's easy enough to adjust when >> fetching. > > I won't re-create the repository from scratch, then. > > Though I would still need an updated version of git to enable lots of > branches and tags without wasting too much hard disk space. > > Can a sourceware admin please install (or build) git 1.6.3.x? If there > are concerns of breaking other things, I could install a local copy in > ~/bin. +overseers I don't see a problem doing this (we definitely don't want two versions installed), but there are real live git projects on sourceware so we should be a bit careful. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-10 0:12 ` Daniel Berlin @ 2009-06-10 0:43 ` Ian Lance Taylor 2009-06-10 1:02 ` Angela Marie Thomas 2009-06-11 7:08 ` git mirror at gcc.gnu.org Bernie Innocenti 0 siblings, 2 replies; 29+ messages in thread From: Ian Lance Taylor @ 2009-06-10 0:43 UTC (permalink / raw) To: Daniel Berlin Cc: Bernie Innocenti, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse Daniel Berlin <dberlin@dberlin.org> writes: > I don't see a problem doing this (we definitely don't want two > versions installed), but there are real live git projects on > sourceware so we should be a bit careful. 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. Ian ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-10 0:43 ` Ian Lance Taylor @ 2009-06-10 1:02 ` Angela Marie Thomas 2009-06-11 7:08 ` git mirror at gcc.gnu.org Bernie Innocenti 1 sibling, 0 replies; 29+ messages in thread From: Angela Marie Thomas @ 2009-06-10 1:02 UTC (permalink / raw) To: Ian Lance Taylor Cc: Daniel Berlin, Bernie Innocenti, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse iant@google.com wrote: > Daniel Berlin <dberlin@dberlin.org> writes: > > > I don't see a problem doing this (we definitely don't want two > > versions installed), but there are real live git projects on > > sourceware so we should be a bit careful. > > 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. Someone should rpm -e the git RPMs as well. --Angela ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-10 0:43 ` Ian Lance Taylor 2009-06-10 1:02 ` Angela Marie Thomas @ 2009-06-11 7:08 ` Bernie Innocenti 2009-06-11 12:04 ` Daniel Berlin 2009-06-12 5:19 ` Jason Merrill 1 sibling, 2 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-11 7:08 UTC (permalink / raw) To: Ian Lance Taylor Cc: Daniel Berlin, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse 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/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-11 7:08 ` git mirror at gcc.gnu.org Bernie Innocenti @ 2009-06-11 12:04 ` Daniel Berlin 2009-06-11 13:18 ` Bernie Innocenti 2009-06-12 5:19 ` Jason Merrill 1 sibling, 1 reply; 29+ messages in thread From: Daniel Berlin @ 2009-06-11 12:04 UTC (permalink / raw) To: Bernie Innocenti Cc: Ian Lance Taylor, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On Thu, Jun 11, 2009 at 3:07 AM, Bernie Innocenti<bernie@codewiz.org> wrote: > 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" > Yeah, this i had forgotten to do ;) > 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. It may be faster for my to rsync it to a 32 core machine, pack it, then rsync it back now that delta compression is threaded. Does it get large enough speedups these days to be worth it? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-11 12:04 ` Daniel Berlin @ 2009-06-11 13:18 ` Bernie Innocenti 2009-06-11 13:22 ` Bernie Innocenti 0 siblings, 1 reply; 29+ messages in thread From: Bernie Innocenti @ 2009-06-11 13:18 UTC (permalink / raw) To: Daniel Berlin Cc: Ian Lance Taylor, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/11/09 14:03, Daniel Berlin wrote: > It may be faster for my to rsync it to a 32 core machine, pack it, > then rsync it back now that delta compression is threaded. > Does it get large enough speedups these days to be worth it? It's done, and the pack came out 553MB. Perhaps packing with an even larger window and depth of 250 might squeeze a few more MBs off... Worth a try :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-11 13:18 ` Bernie Innocenti @ 2009-06-11 13:22 ` Bernie Innocenti 0 siblings, 0 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-11 13:22 UTC (permalink / raw) To: Daniel Berlin Cc: Ian Lance Taylor, overseers, Jason Merrill, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/11/09 15:18, Bernie Innocenti wrote: > On 06/11/09 14:03, Daniel Berlin wrote: >> It may be faster for my to rsync it to a 32 core machine, pack it, >> then rsync it back now that delta compression is threaded. >> Does it get large enough speedups these days to be worth it? > > It's done, and the pack came out 553MB. > > Perhaps packing with an even larger window and depth of 250 might > squeeze a few more MBs off... Worth a try :-) BTW, I'd be curious to see how much 32 cores can speed up packing. By default, git-repack autodetects the number of CPUs and spawns threads accordingly, so it shouldn't require any tuning. You just need a recent version of git implementing this optimization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-11 7:08 ` git mirror at gcc.gnu.org Bernie Innocenti 2009-06-11 12:04 ` Daniel Berlin @ 2009-06-12 5:19 ` Jason Merrill 2009-06-15 14:28 ` Rafael Espindola 1 sibling, 1 reply; 29+ messages in thread From: Jason Merrill @ 2009-06-12 5:19 UTC (permalink / raw) To: Bernie Innocenti Cc: Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/11/2009 03:07 AM, Bernie Innocenti wrote: > 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. Mine are. I ignore all heads in gcc.git, and just map its remotes into my remotes by manually specifying remote.origin.fetch. Not very pretty, but it seems to produce the optimal result. See my stuff in the lower section of http://gcc.gnu.org/wiki/GitMirror for more details. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-12 5:19 ` Jason Merrill @ 2009-06-15 14:28 ` Rafael Espindola 2009-06-15 15:18 ` Jason Merrill 2009-06-15 17:22 ` Bernie Innocenti 0 siblings, 2 replies; 29+ messages in thread From: Rafael Espindola @ 2009-06-15 14:28 UTC (permalink / raw) To: Jason Merrill Cc: Bernie Innocenti, Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse > Mine are. I ignore all heads in gcc.git, and just map its remotes into my > remotes by manually specifying remote.origin.fetch. Not very pretty, but it > seems to produce the optimal result. See my stuff in the lower section of > http://gcc.gnu.org/wiki/GitMirror for more details. It fails with $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' $ git fetch fatal: refs/remotes/origin/gcc-4_0-branch tracks both refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch > Jason > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-15 14:28 ` Rafael Espindola @ 2009-06-15 15:18 ` Jason Merrill 2009-06-15 17:22 ` Bernie Innocenti 1 sibling, 0 replies; 29+ messages in thread From: Jason Merrill @ 2009-06-15 15:18 UTC (permalink / raw) To: Rafael Espindola Cc: Bernie Innocenti, Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/15/2009 10:28 AM, Rafael Espindola wrote: > It fails with > > $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' That's not my section; my contribution starts at Alternative git-svn procedure (Jason Merrill) Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-15 14:28 ` Rafael Espindola 2009-06-15 15:18 ` Jason Merrill @ 2009-06-15 17:22 ` Bernie Innocenti 2009-06-16 14:17 ` Jason Merrill 2009-06-16 15:17 ` Jason Merrill 1 sibling, 2 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-15 17:22 UTC (permalink / raw) To: Rafael Espindola Cc: Jason Merrill, Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/15/09 16:28, Rafael Espindola wrote: >> Mine are. I ignore all heads in gcc.git, and just map its remotes into my >> remotes by manually specifying remote.origin.fetch. Not very pretty, but it >> seems to produce the optimal result. See my stuff in the lower section of >> http://gcc.gnu.org/wiki/GitMirror for more details. > > It fails with > > $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' > $ git fetch > fatal: refs/remotes/origin/gcc-4_0-branch tracks both > refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch Perhaps I should remove those "friendly" refs pointing at the remote branches? Or can we find a better alternative? Their use was to make a few frequently used branches readily visible in gitweb and with a simple clone. Perhaps git-svn could be configured to map svn branches directly to the local namespace instead of remotes/ ? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-15 17:22 ` Bernie Innocenti @ 2009-06-16 14:17 ` Jason Merrill 2009-06-16 14:21 ` Daniel Berlin 2009-06-16 15:17 ` Jason Merrill 1 sibling, 1 reply; 29+ messages in thread From: Jason Merrill @ 2009-06-16 14:17 UTC (permalink / raw) To: Bernie Innocenti Cc: Rafael Espindola, Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/15/2009 01:22 PM, Bernie Innocenti wrote: > On 06/15/09 16:28, Rafael Espindola wrote: >> It fails with >> >> $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' >> $ git fetch >> fatal: refs/remotes/origin/gcc-4_0-branch tracks both >> refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch > > Perhaps I should remove those "friendly" refs pointing at the remote > branches? Or can we find a better alternative? Their use was to make a > few frequently used branches readily visible in gitweb and with a simple > clone. It makes sense to me to have the friendly refs so that the simple case (clone, don't try to use svn directly) works easily. What I'm doing doesn't have any problem with them. Rafael was following older instructions written by someone else. When I started editing that page, I put my suggestions at the bottom because I was fairly new to git. Now I feel more confident that what I'm doing is right (or at least better) so I think I'll remove the old instructions. But what are oldmaster/pre-globals-git/restrict-git? And why have both "master" and "trunk" as heads? > Perhaps git-svn could be configured to map svn branches directly to the > local namespace instead of remotes/ ? It could, but it seems unnecessary. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-16 14:17 ` Jason Merrill @ 2009-06-16 14:21 ` Daniel Berlin 2009-06-16 19:52 ` Bernie Innocenti 0 siblings, 1 reply; 29+ messages in thread From: Daniel Berlin @ 2009-06-16 14:21 UTC (permalink / raw) To: Jason Merrill Cc: Bernie Innocenti, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On Tue, Jun 16, 2009 at 10:17 AM, Jason Merrill<jason@redhat.com> wrote: > On 06/15/2009 01:22 PM, Bernie Innocenti wrote: >> >> On 06/15/09 16:28, Rafael Espindola wrote: >>> >>> It fails with >>> >>> $ git config --add remote.origin.fetch >>> '+refs/remotes/*:refs/remotes/origin/*' >>> $ git fetch >>> fatal: refs/remotes/origin/gcc-4_0-branch tracks both >>> refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch >> >> Perhaps I should remove those "friendly" refs pointing at the remote >> branches? Or can we find a better alternative? Their use was to make a >> few frequently used branches readily visible in gitweb and with a simple >> clone. > > It makes sense to me to have the friendly refs so that the simple case > (clone, don't try to use svn directly) works easily. > > What I'm doing doesn't have any problem with them. Rafael was following > older instructions written by someone else. When I started editing that > page, I put my suggestions at the bottom because I was fairly new to git. > Now I feel more confident that what I'm doing is right (or at least better) > so I think I'll remove the old instructions. > > But what are oldmaster/pre-globals-git/restrict-git? pre-globals-git and restrict-git were test branches from an old mostly broken version. ;) They are dead and if someone wants to manually remove the refs, go for it. No idea what oldmaster is. > And why have both > "master" and "trunk" as heads? > See "broken" ;) >> Perhaps git-svn could be configured to map svn branches directly to the >> local namespace instead of remotes/ ? > > It could, but it seems unnecessary. > > Jason > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-16 14:21 ` Daniel Berlin @ 2009-06-16 19:52 ` Bernie Innocenti 2009-06-18 16:39 ` Jason Merrill 2009-06-20 3:00 ` Jason Merrill 0 siblings, 2 replies; 29+ messages in thread From: Bernie Innocenti @ 2009-06-16 19:52 UTC (permalink / raw) To: Daniel Berlin Cc: Jason Merrill, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse Daniel Berlin wrote: > pre-globals-git and restrict-git were test branches from an old mostly > broken version. ;) > > They are dead and if someone wants to manually remove the refs, go for it. > No idea what oldmaster is. Done. >> And why have both >> "master" and "trunk" as heads? > > See "broken" ;) Yes, but which one should die? Will cloners get confused by a repository where the master branch is missing? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-16 19:52 ` Bernie Innocenti @ 2009-06-18 16:39 ` Jason Merrill 2009-06-20 3:00 ` Jason Merrill 1 sibling, 0 replies; 29+ messages in thread From: Jason Merrill @ 2009-06-18 16:39 UTC (permalink / raw) To: Bernie Innocenti Cc: Daniel Berlin, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse I also notice a few remotes with @ in them like milepost-branch@129596 which seem to be git-svn artifacts. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-16 19:52 ` Bernie Innocenti 2009-06-18 16:39 ` Jason Merrill @ 2009-06-20 3:00 ` Jason Merrill 2009-06-20 8:38 ` Bernie Innocenti 1 sibling, 1 reply; 29+ messages in thread From: Jason Merrill @ 2009-06-20 3:00 UTC (permalink / raw) To: Bernie Innocenti Cc: Daniel Berlin, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/16/2009 03:51 PM, Bernie Innocenti wrote: > Yes, but which one should die? Will cloners get confused by a > repository where the master branch is missing? clone will get whatever branch is currently active in the cloned repository, doesn't matter what it's called. Currently master is out of date, so it's worse than nothing. Any thoughts on what to do about the non-branch directories under branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse ubuntu. The only solution I can think of would be to specifically enumerate which branches we want to mirror in git with separate git-svn fetch lines rather than use the branches= line. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-20 3:00 ` Jason Merrill @ 2009-06-20 8:38 ` Bernie Innocenti 2009-06-22 15:42 ` Jason Merrill 0 siblings, 1 reply; 29+ messages in thread From: Bernie Innocenti @ 2009-06-20 8:38 UTC (permalink / raw) To: Jason Merrill Cc: Daniel Berlin, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/20/09 04:59, Jason Merrill wrote: > clone will get whatever branch is currently active in the cloned > repository, doesn't matter what it's called. > > Currently master is out of date, so it's worse than nothing. Ok, culled. > Any thoughts on what to do about the non-branch directories under > branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse > ubuntu. The only solution I can think of would be to specifically > enumerate which branches we want to mirror in git with separate git-svn > fetch lines rather than use the branches= line. Don't we want to mirror all branches? Enumerating them all would be a lot of work... Perhaps we could report this missing feature to the git-svn folks and ask them to fix it for us? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-20 8:38 ` Bernie Innocenti @ 2009-06-22 15:42 ` Jason Merrill 0 siblings, 0 replies; 29+ messages in thread From: Jason Merrill @ 2009-06-22 15:42 UTC (permalink / raw) To: Bernie Innocenti Cc: Daniel Berlin, Rafael Espindola, Ian Lance Taylor, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse On 06/20/2009 04:38 AM, Bernie Innocenti wrote: > On 06/20/09 04:59, Jason Merrill wrote: >> Any thoughts on what to do about the non-branch directories under >> branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse >> ubuntu. The only solution I can think of would be to specifically >> enumerate which branches we want to mirror in git with separate git-svn >> fetch lines rather than use the branches= line. > > Don't we want to mirror all branches? Enumerating them all would be a > lot of work... I was thinking to do that programatically. i.e. git config --unset svn-remote.svn.branches for f in `svn ls svn://gcc.gnu.org/svn/gcc/branches|egrep -v '^(ARM|apple|csl|dead|gcj|ibm|ix86|redhat|suse|ubuntu)/'`; do f=${f%/} git config --get-all svn-remote.svn.fetch | fgrep "branches/$f:" > /dev/null || git config --add svn-remote.svn.fetch branches/$f:refs/remotes/$f done for d in ARM apple csl dead gcj ibm ix86 redhat suse ubuntu; do for f in `svn ls svn://gcc.gnu.org/svn/gcc/branches/$d`; do f=$d/${f%/} git config --get-all svn-remote.svn.fetch | fgrep "branches/$f:" > /dev/null || git config --add svn-remote.svn.fetch branches/$f:refs/remotes/$f done done > Perhaps we could report this missing feature to the git-svn folks and > ask them to fix it for us? I'm not sure it's possible in general to tell whether a particular directory in SVN is a branch or not. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at gcc.gnu.org 2009-06-15 17:22 ` Bernie Innocenti 2009-06-16 14:17 ` Jason Merrill @ 2009-06-16 15:17 ` Jason Merrill 1 sibling, 0 replies; 29+ messages in thread From: Jason Merrill @ 2009-06-16 15:17 UTC (permalink / raw) To: Bernie Innocenti Cc: Rafael Espindola, Ian Lance Taylor, Daniel Berlin, overseers, Ralf Wildenhues, gcc, Harvey Harrison, David Woodhouse Incidentally, I notice that branches in subdirectories of branches/ are still broken; i.e. ARM apple redhat suse ubuntu, maybe others. I give instructions on the GitMirror page for how to deal with that, but I wonder if it's possible to set it up properly on the mirror instead. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-09 19:17 ` Bernie Innocenti 2009-06-10 0:12 ` Daniel Berlin @ 2009-06-11 1:38 ` Jason Merrill 2009-06-11 6:28 ` Daniel Berlin 1 sibling, 1 reply; 29+ messages in thread From: Jason Merrill @ 2009-06-11 1:38 UTC (permalink / raw) To: Bernie Innocenti Cc: Ralf Wildenhues, GCC, Harvey Harrison, David Woodhouse, Daniel Berlin Bernie Innocenti wrote: > I won't re-create the repository from scratch, then. re-creating it from scratch should be fine as long as the metadata uses svn+ssh://gcc.gnu.org/svn/gcc. I'd think that git svn clone -s file://path/to/svn/root \ --rewrite-root=svn+ssh://gcc.gnu.org/svn/gcc would be the way to go. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: git mirror at infradead? 2009-06-11 1:38 ` git mirror at infradead? Jason Merrill @ 2009-06-11 6:28 ` Daniel Berlin 0 siblings, 0 replies; 29+ messages in thread From: Daniel Berlin @ 2009-06-11 6:28 UTC (permalink / raw) To: Jason Merrill Cc: Bernie Innocenti, Ralf Wildenhues, GCC, Harvey Harrison, David Woodhouse On Wed, Jun 10, 2009 at 9:38 PM, Jason Merrill<jason@redhat.com> wrote: > Bernie Innocenti wrote: >> >> I won't re-create the repository from scratch, then. > > re-creating it from scratch should be fine as long as the metadata uses > svn+ssh://gcc.gnu.org/svn/gcc. I'd think that > > git svn clone -s file://path/to/svn/root \ > --rewrite-root=svn+ssh://gcc.gnu.org/svn/gcc > > would be the way to go. Unless git svn fixed a bug i reported about rewrite roots, this will crash eventually. I had to work around it with some hacks :( > > Jason > ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2009-06-22 15:42 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-07 5:22 git mirror at infradead? Ralf Wildenhues 2009-06-07 10:18 ` Bernie Innocenti 2009-06-07 10:40 ` Ralf Wildenhues 2009-06-07 11:38 ` Bernie Innocenti 2009-06-07 12:08 ` Bernie Innocenti 2009-06-07 21:55 ` Daniel Berlin 2009-06-09 14:18 ` Jason Merrill 2009-06-09 19:17 ` Bernie Innocenti 2009-06-10 0:12 ` Daniel Berlin 2009-06-10 0:43 ` Ian Lance Taylor 2009-06-10 1:02 ` Angela Marie Thomas 2009-06-11 7:08 ` git mirror at gcc.gnu.org Bernie Innocenti 2009-06-11 12:04 ` Daniel Berlin 2009-06-11 13:18 ` Bernie Innocenti 2009-06-11 13:22 ` Bernie Innocenti 2009-06-12 5:19 ` Jason Merrill 2009-06-15 14:28 ` Rafael Espindola 2009-06-15 15:18 ` Jason Merrill 2009-06-15 17:22 ` Bernie Innocenti 2009-06-16 14:17 ` Jason Merrill 2009-06-16 14:21 ` Daniel Berlin 2009-06-16 19:52 ` Bernie Innocenti 2009-06-18 16:39 ` Jason Merrill 2009-06-20 3:00 ` Jason Merrill 2009-06-20 8:38 ` Bernie Innocenti 2009-06-22 15:42 ` Jason Merrill 2009-06-16 15:17 ` Jason Merrill 2009-06-11 1:38 ` git mirror at infradead? Jason Merrill 2009-06-11 6:28 ` Daniel Berlin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).