NOTICE: Gitolite migration is complete.
All, Push access is now restored and Gitolite is in place! This brings some nice updates: * There's now access to the 'git' protocol for cloning anonymously. This lets you clone even the biggest repos extremely quickly, and is the fastest method for getting a copy of the tree. * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, meaning it should be faster too! * We will soon have Gitweb available, once our git.haskell.org CNAME is in place. Eventually we'd like something akin to https://git.kernel.org/cgit/ possibly. * None of you have shell access to ghc.haskell.org anymore (well, this is a nice update for us administrators :) The following people have had their keys re-added, and should be able to push and pull from the new setup. * Andreas Voellmy * Austin Seipp * Ben Lippmeier * Iavor Diatchki * David Terei * David Waern * Dimitrios Vytiniotis * Duncan Coutts * Edsko de Vries * Erik de Castro Lopo * Edward Yang * Geoffrey Mainland * Gabor Greif * Herbert Valerio Riedel * Ian Lynagh * Ilya Sergey * Johan Tibell * José Pedro Magalhães * Jan Stolarek * Manuel Chakravarty * Max Bolingbroke * Nicholas Frisby * Paolo Capriotti * Richard Eisenberg * Roman Leshchinskiy * Ross Patterson * Simon Hengel * Simon Marlow * Simon Peyton Jones * Thomas Schilling The following people still have shell access for any administrative needs: * Austin Seipp (and the remaining haskell.org infrastructure team.) * Herbert Valerio Riedel * Ian Lynagh I have undoubtedly missed some people. Please talk to me and we'll get you set up! If you're a developer, please read about developer changes here: * http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan#Developerchanges TL;DR: if you have an old tree, run the following four commands from the root to fix the push/pull URLs. $ git checkout master $ git pull https://github.com/ghc/ghc.git master $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url origin $ ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin The reason you must get the latest-copy of ./sync-all is because Herbert made some last minute bug fixes. Technically, you could just download the latest copy and run it directly, but this is easier and fairly straight forward. Please direct any concerns to me, like if you need something off the server, need your shell account back, or need commit access. Over the next few days, I'll be cleaning up the wiki - updating references and guides on how to check out the source for users and developer. I also might be sending out some emails with questions while we refine the new setup in the next few days (there were some Trac integration changes.) Also, a gigantic applause for Herbert, who did a lot of the work here! -- Regards, Austin - PGP: 4096R/0x91384671
On 9 Aug 2013, at 23:19, Austin Seipp wrote:
* None of you have shell access to ghc.haskell.org anymore (well, this is a nice update for us administrators :)
Is ghc.haskell.org the same machine as darcs.haskell.org? I notice that my nightly build of nhc98 failed a few hours ago with the error: darcs failed: Not a repository: darcs.haskell.org:/home/darcs/nhc98 ((scp) failed to fetch: darcs.haskell.org:/home/darcs/nhc98/_darcs/inventory) whilst it certainly succeeded the night before. Also, manual use of ssh now refuses me access to the machine: $ ssh darcs.haskell.org Permission denied (publickey). Anything you can do to fix that? Darcs depends on the ssh protocol for transfers. Regards, Malcolm
Hello Malcolm, On 2013-08-10 at 09:57:34 +0200, Malcolm Wallace wrote:
* None of you have shell access to ghc.haskell.org anymore (well, this is a nice update for us administrators :) Is ghc.haskell.org the same machine as darcs.haskell.org?
Yes
I notice that my nightly build of nhc98 failed a few hours ago with the error:
darcs failed: Not a repository: darcs.haskell.org:/home/darcs/nhc98 ((scp) failed to fetch: darcs.haskell.org:/home/darcs/nhc98/_darcs/inventory)
whilst it certainly succeeded the night before. Also, manual use of ssh now refuses me access to the machine:
$ ssh darcs.haskell.org Permission denied (publickey).
Anything you can do to fix that? Darcs depends on the ssh protocol for transfers.
Btw, I assumed Darcs required only ssh for write access to a Darcs repo? However, if this helps, we could create a user account 'darcs' (in the style of the current 'git' gitolite user) with a darcs-wrapper.pl and add the ssh pubkeys from users needing darcs/ssh access as described in [1]; this would still satisfy the least-privilege principle as no full shell account would be given out on ghc.haskell.org. Would that help? [1]: http://darcs.net/RepoViaSSH
Hello GHC Devs, Let me add some details and clarifications to yesterday's migration completion notice: On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
Push access is now restored and Gitolite is in place! This brings some nice updates:
* There's now access to the 'git' protocol for cloning anonymously. This lets you clone even the biggest repos extremely quickly, and is the fastest method for getting a copy of the tree.
Consequently, if you are a developer (and not behind a firewall that filters port 9418) you should try out the following assymetric configuration: ./sync-all -r git://ghc.haskell.org remote set-url origin ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin This uses the unauthenticated low-latency git:// protocol for fetching repository data, and the authenticated encrypted high-latency ssh:// protocol for pushing into the GHC repositories. This setup has the advantage over using the GitHub GHC mirrors, that the fetch and push locations are really identical and never out-of-sync (e.g. if the Git mirroring breaks or lags for some reason)
* Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, meaning it should be faster too! * We will soon have Gitweb available, once our git.haskell.org CNAME is in place. Eventually we'd like something akin to
Small clarification: Smart HTTP Git transport is only enabled on http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/ are is still served "dumbly". If you don't want to wait for the DNS CNAME entry, you can fake the DNS entry to point to ghc.haskell.org, e.g. by echo "88.198.224.241 git.haskell.org" >> /etc/hosts (...and don't forget to remove that entry once the real DNS CNAME entry is in place) and then just point your browser to http://git.haskell.org/
The following people have had their keys re-added, and should be able to push and pull from the new setup. [...]
You should all check your current permissions by invoking ssh git@ghc.haskell.org info you should see something like ,---- | hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4 | the gitolite config gives you the following access: | @R W ghc | @R W ghc-tarballs | @R W git-sandbox | @R W haddock | [...] | @R W packages/unix | @R W packages/vector | @R W packages/xhtml | @R W testsuite `---- Please make sure, *YOUR* username shows up in place of $USERNAME, to find out whether we mixed up your public keys. (See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want to know more about the meaning of the output) Note: The current setup denies non-fast-forward and ref-deletion updates via "git push". This will be relaxed once we reach an agreement over what the Git heads/tag refs namespace policy shall be (i.e. who is allowed to create/delete/non-fwd-update heads/tags (and which ones)). If you want to debug/test 'git push', feel free to push whatever you like to the 'git-sandbox' repository.
Please direct any concerns to me, like if you need something off the server, need your shell account back, or need commit access.
For technical problems with Trac&Git(olite) itself, please CC me as well; as I am in a different timezone from Austin, this may help reduce the response time for solving the issue at hand. Alternatively, you can also reach us on freenode's #haskell-infrastructure And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly. Cheers, hvr
On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote:
And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly.
The new post-receive hook for notifying Trac about new commits has been updated to use Trac's CommitTicketUpdater[1] One of the changes is the way commit messages are added to a ticket comment: - Previously, the commit message was put into a verbatim code block, as in http://ghc.haskell.org/trac/ghc/ticket/8121#comment:2 - Now, the commit message is wrapped in a code block using Trac's CommitTicketReference wiki processor which effectively interprets the commit message as Trac wiki markup[2]. This is more consistent with the way commit messages are exposed in other places throughout Trac and allows for proper Wiki and URL links in the ticket comment view. For instance, http://ghc.haskell.org/trac/ghc/ticket/8121#comment:3 As for *when* a Git commit is actually associated with a ticket: - Currently, only the 4 Git repos associated with GHC Trac (ghc,nofib,testuite,base; [3]) are scanned for ticket references. - Currently, only if a commit becomes reachable during a "git push" from the 'master' branch it gets scanned for trigger words. This is the simplest way to avoid duplicate commit messages getting added as comments to tickets (and avoid premature ticket closing).[4] - The ticket-referencing syntax explained below must be used, for the ticket reference to get recognized. To quote the documentation[1]: ,---- | The basic syntax is of the form [command] [ticketreference]. A colon | between the command and the ticket reference is allowed. The | ticketreference also allows to list multiple ticket numbers separated by | spaces and/or comma. The word 'and' is also allowed between ticket | numbers. | | You can optionally refer to tickets with the following words | | ticket, issue, bug | Examples (note: not verified!): | | close #10 | closed: #10 | closes ticket #10 | closes ticket:10 | fixes #10 | fixes bug: #10 | see issue #5 | references #5, #6 | fixes bug #10 and #11 | | A fairly complicated example of what you can do is with a commit | message of: | | Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12. | | This will close #10 and #12, and add a note to #12. `---- The command verbs currently recognized for referencing a ticket are currently: | addressing addresses re references refs see Trac ...and the verbs currently recognized for referencing *and* closing a ticket are | close closed closes fix fixed fixes Consequently, if you just write "Fixes Trac #1234" in your commit (which occurs quite often in the git history), this will only reference the ticket but *not* close the ticket. If closing from commits is not desired or causes problems, we can move the close/fix verbs into the "reference-only" set of verbs and be done with it. If there's something you'd like to behave differently, please tell us. If accomplishable with reasonable effort, we're happy to implement it. The information from this posting may/should/shall/will be put on the GHC Trac Wiki as well for future reference. Cheers, hvr [1]: http://trac.edgewall.org/wiki/CommitTicketUpdater [2]: http://ghc.haskell.org/trac/ghc/wiki/WikiFormatting [3]: http://ghc.haskell.org/trac/ghc/browser [4]: Should the need arise, we can consider a more sophisticated approach can be used, which would consider commits in more than just the 'master' branch.
On 10/08/13 10:57, Herbert Valerio Riedel wrote:
The command verbs currently recognized for referencing a ticket are currently:
| addressing addresses re references refs see Trac
...and the verbs currently recognized for referencing *and* closing a ticket are
| close closed closes fix fixed fixes
Consequently, if you just write "Fixes Trac #1234" in your commit (which occurs quite often in the git history), this will only reference the ticket but *not* close the ticket.
If closing from commits is not desired or causes problems, we can move the close/fix verbs into the "reference-only" set of verbs and be done with it.
One reason that we didn't enable this feature before was that we often want to move the ticket into the merge state after committing the fix. So perhaps we should either have a new keyword ("mergefix"?) for fixes we want to merge, or we should not have the auto-close behaviour. Cheers, Simon
Herbert My gut feel is that it's fragile and unexpected to have tickets change status based on commit messages. Revisiting the ticket itself can remind you that the fix is only partial, or that there is another related ticket to look at, or that you need to add a regression test, or something else Too much automation can be confusing. I'd suggest (fairly strongly -- but resist if you feel otherwise) making status changes only based on explicit user actions. It doesn't take long to do! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon | Marlow | Sent: 13 August 2013 13:17 | To: Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: New Git-commit-message -> Trac-ticket interaction | | On 10/08/13 10:57, Herbert Valerio Riedel wrote: | | > The command verbs currently recognized for referencing a ticket are | > currently: | > | > | addressing addresses re references refs see Trac | > | > ...and the verbs currently recognized for referencing *and* closing a | > ticket are | > | > | close closed closes fix fixed fixes | > | > Consequently, if you just write "Fixes Trac #1234" in your commit (which | > occurs quite often in the git history), this will only reference the | > ticket but *not* close the ticket. | > | > If closing from commits is not desired or causes problems, we can move | > the close/fix verbs into the "reference-only" set of verbs and be done | > with it. | | One reason that we didn't enable this feature before was that we often | want to move the ticket into the merge state after committing the fix. | | So perhaps we should either have a new keyword ("mergefix"?) for fixes | we want to merge, or we should not have the auto-close behaviour. | | Cheers, | Simon | | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
Hello Simon, On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
My gut feel is that it's fragile and unexpected to have tickets change status based on commit messages. Revisiting the ticket itself can remind you that the fix is only partial, or that there is another related ticket to look at, or that you need to add a regression test, or something else
Too much automation can be confusing. I'd suggest (fairly strongly -- but resist if you feel otherwise) making status changes only based on explicit user actions. It doesn't take long to do!
Well, I'm somewhat convinced (and I don't have a solution to offer addressing your concerns at the moment). Moreover, as it's easier right now to just configure more or less what the previous semantics were and post-pone devising a more elaborate ticket/commit action command system, I've reconfigured the Trac instance as follows: - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in a commit's message (which became newly reachable from the `master` branch with the current `git push` operation), the commit is added as a comment to the referenced ticket. - Aside from adding comments to a ticket, no other actions are triggered by Git commit messages. Is this acceptable? Cheers, hvr
On 15/08/13 14:36, Herbert Valerio Riedel wrote:
Hello Simon,
On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
My gut feel is that it's fragile and unexpected to have tickets change status based on commit messages. Revisiting the ticket itself can remind you that the fix is only partial, or that there is another related ticket to look at, or that you need to add a regression test, or something else
Too much automation can be confusing. I'd suggest (fairly strongly -- but resist if you feel otherwise) making status changes only based on explicit user actions. It doesn't take long to do!
Well, I'm somewhat convinced (and I don't have a solution to offer addressing your concerns at the moment).
Moreover, as it's easier right now to just configure more or less what the previous semantics were and post-pone devising a more elaborate ticket/commit action command system, I've reconfigured the Trac instance as follows:
- As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in a commit's message (which became newly reachable from the `master` branch with the current `git push` operation), the commit is added as a comment to the referenced ticket.
- Aside from adding comments to a ticket, no other actions are triggered by Git commit messages.
Is this acceptable?
That's great. I also quite liked the previous behaviour. Cheers, Simon
| - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in | a commit's message (which became newly reachable from the `master` | branch with the current `git push` operation), the commit is added as | a comment to the referenced ticket. | | - Aside from adding comments to a ticket, no other actions are | triggered by Git commit messages. | | Is this acceptable? That sounds good to me, thanks. Don't forget to update the wiki though. Thanks Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvr@gnu.org] | Sent: 15 August 2013 14:36 | To: Simon Peyton-Jones | Cc: Herbert Valerio Riedel; Simon Marlow; ghc-devs@haskell.org | Subject: Previous commit ticket ref syntax restored (was: New Git-commit- | message -> Trac-ticket interaction) | | Hello Simon, | | On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote: | > My gut feel is that it's fragile and unexpected to have tickets change | > status based on commit messages. Revisiting the ticket itself can | > remind you | > that the fix is only partial, or | > that there is another related ticket to look at, or | > that you need to add a regression test, or | > something else | > | > Too much automation can be confusing. I'd suggest (fairly strongly -- | > but resist if you feel otherwise) making status changes only based on | > explicit user actions. It doesn't take long to do! | | Well, I'm somewhat convinced (and I don't have a solution to offer | addressing your concerns at the moment). | | Moreover, as it's easier right now to just configure more or less what the previous | semantics were and post-pone devising a more elaborate ticket/commit action | command system, I've reconfigured the Trac instance as follows: | | - As soon as a ticket-reference matching the regexp '#[0-9]+' occurs in | a commit's message (which became newly reachable from the `master` | branch with the current `git push` operation), the commit is added as | a comment to the referenced ticket. | | - Aside from adding comments to a ticket, no other actions are | triggered by Git commit messages. | | Is this acceptable? | | Cheers, | hvr
Just in case there are other people (like me) who didn't notice this, the syntax for telling git that you want to update a Trac ticket in the commit log has changed. Read Herbet's message for details. I used to just mention the ticket number in the commit message "blah blah (#1234)", the new syntax for this is "blah blah (see #1234)". I have updated http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention this, but it could probably do with more complete docs since the standard Trac docs don't take into account our local settings. Herbert, could you expand that please? Cheers, Simon On 10/08/13 10:57, Herbert Valerio Riedel wrote:
On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote:
And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly.
The new post-receive hook for notifying Trac about new commits has been updated to use Trac's CommitTicketUpdater[1]
One of the changes is the way commit messages are added to a ticket comment:
- Previously, the commit message was put into a verbatim code block, as in http://ghc.haskell.org/trac/ghc/ticket/8121#comment:2
- Now, the commit message is wrapped in a code block using Trac's CommitTicketReference wiki processor which effectively interprets the commit message as Trac wiki markup[2]. This is more consistent with the way commit messages are exposed in other places throughout Trac and allows for proper Wiki and URL links in the ticket comment view.
For instance, http://ghc.haskell.org/trac/ghc/ticket/8121#comment:3
As for *when* a Git commit is actually associated with a ticket:
- Currently, only the 4 Git repos associated with GHC Trac (ghc,nofib,testuite,base; [3]) are scanned for ticket references.
- Currently, only if a commit becomes reachable during a "git push" from the 'master' branch it gets scanned for trigger words. This is the simplest way to avoid duplicate commit messages getting added as comments to tickets (and avoid premature ticket closing).[4]
- The ticket-referencing syntax explained below must be used, for the ticket reference to get recognized.
To quote the documentation[1]:
,---- | The basic syntax is of the form [command] [ticketreference]. A colon | between the command and the ticket reference is allowed. The | ticketreference also allows to list multiple ticket numbers separated by | spaces and/or comma. The word 'and' is also allowed between ticket | numbers. | | You can optionally refer to tickets with the following words | | ticket, issue, bug | Examples (note: not verified!): | | close #10 | closed: #10 | closes ticket #10 | closes ticket:10 | fixes #10 | fixes bug: #10 | see issue #5 | references #5, #6 | fixes bug #10 and #11 | | A fairly complicated example of what you can do is with a commit | message of: | | Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12. | | This will close #10 and #12, and add a note to #12. `----
The command verbs currently recognized for referencing a ticket are currently:
| addressing addresses re references refs see Trac
...and the verbs currently recognized for referencing *and* closing a ticket are
| close closed closes fix fixed fixes
Consequently, if you just write "Fixes Trac #1234" in your commit (which occurs quite often in the git history), this will only reference the ticket but *not* close the ticket.
If closing from commits is not desired or causes problems, we can move the close/fix verbs into the "reference-only" set of verbs and be done with it.
If there's something you'd like to behave differently, please tell us. If accomplishable with reasonable effort, we're happy to implement it.
The information from this posting may/should/shall/will be put on the GHC Trac Wiki as well for future reference.
Cheers, hvr
[1]: http://trac.edgewall.org/wiki/CommitTicketUpdater [2]: http://ghc.haskell.org/trac/ghc/wiki/WikiFormatting [3]: http://ghc.haskell.org/trac/ghc/browser [4]: Should the need arise, we can consider a more sophisticated approach can be used, which would consider commits in more than just the 'master' branch.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
On 2013-08-13 at 14:20:59 +0200, Simon Marlow wrote: [...]
I have updated http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention this, but it could probably do with more complete docs since the standard Trac docs don't take into account our local settings.
Herbert, could you expand that please?
I've just expanded that section; please review I've added a reference to [1] (even though almost all commit messages I've seen already follow that convention anyway). I refrained from mentioning some of the additional syntax variants recognized by the commit message parser (such as "closes issue 1234" as alternative for "closes #1234") as it makes grepping through commit messages more difficult. While at it, I added "resolve{,s,ed}" to the list of verbs to mimic GitHub's supported keywords[2]. Btw, if this is desired, we could make a commit add a ticket comment as soon as the respective ticket-number occurs (i.e. w/o any preceding verb). This would effectively make Trac recognize a subset of GitHub's syntax. I could implement this together with the mergefix-verb feature you proposed. [1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html [2]: https://help.github.com/articles/closing-issues-via-commit-messages Cheers, hvr
Btw, if this is desired, we could make a commit add a ticket comment as soon as the respective ticket-number occurs (i.e. w/o any preceding verb).
I consider this useful. I want to write commit messages in the tesuite like "Add regression test for #1234" instead of "Add regression test. See #1234" or sth even more awkward. Janek
What happened to the libraries repositories? ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://ghc.haskell.org/libraries/binary pushurl = ssh://git@ghc.haskell.org/libraries/binary [branch "master"] remote = origin merge = refs/heads/master ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ git pull fatal: remote error: access denied or repository not exported: /libraries/binary Edward Excerpts from Herbert Valerio Riedel's message of Sat Aug 10 05:06:06 -0400 2013:
Hello GHC Devs,
Let me add some details and clarifications to yesterday's migration completion notice:
On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
Push access is now restored and Gitolite is in place! This brings some nice updates:
* There's now access to the 'git' protocol for cloning anonymously. This lets you clone even the biggest repos extremely quickly, and is the fastest method for getting a copy of the tree.
Consequently, if you are a developer (and not behind a firewall that filters port 9418) you should try out the following assymetric configuration:
./sync-all -r git://ghc.haskell.org remote set-url origin ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin
This uses the unauthenticated low-latency git:// protocol for fetching repository data, and the authenticated encrypted high-latency ssh:// protocol for pushing into the GHC repositories.
This setup has the advantage over using the GitHub GHC mirrors, that the fetch and push locations are really identical and never out-of-sync (e.g. if the Git mirroring breaks or lags for some reason)
* Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, meaning it should be faster too! * We will soon have Gitweb available, once our git.haskell.org CNAME is in place. Eventually we'd like something akin to
Small clarification: Smart HTTP Git transport is only enabled on http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/ are is still served "dumbly".
If you don't want to wait for the DNS CNAME entry, you can fake the DNS entry to point to ghc.haskell.org, e.g. by
echo "88.198.224.241 git.haskell.org" >> /etc/hosts
(...and don't forget to remove that entry once the real DNS CNAME entry is in place) and then just point your browser to http://git.haskell.org/
The following people have had their keys re-added, and should be able to push and pull from the new setup. [...]
You should all check your current permissions by invoking
ssh git@ghc.haskell.org info
you should see something like
,---- | hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4 | the gitolite config gives you the following access: | @R W ghc | @R W ghc-tarballs | @R W git-sandbox | @R W haddock | [...] | @R W packages/unix | @R W packages/vector | @R W packages/xhtml | @R W testsuite `----
Please make sure, *YOUR* username shows up in place of $USERNAME, to find out whether we mixed up your public keys.
(See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want to know more about the meaning of the output)
Note: The current setup denies non-fast-forward and ref-deletion updates via "git push". This will be relaxed once we reach an agreement over what the Git heads/tag refs namespace policy shall be (i.e. who is allowed to create/delete/non-fwd-update heads/tags (and which ones)).
If you want to debug/test 'git push', feel free to push whatever you like to the 'git-sandbox' repository.
Please direct any concerns to me, like if you need something off the server, need your shell account back, or need commit access.
For technical problems with Trac&Git(olite) itself, please CC me as well; as I am in a different timezone from Austin, this may help reduce the response time for solving the issue at hand. Alternatively, you can also reach us on freenode's #haskell-infrastructure
And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly.
Cheers, hvr
Hello Edward, On 2013-08-13 at 15:39:20 +0200, Edward Z. Yang wrote:
What happened to the libraries repositories?
They are still there, but only in the /packages directory (as declared in the 'packages' file in the remotepath columns, see also [1]); you need to run
./sync-all -r git://ghc.haskell.org remote set-url origin ./sync-all -r ssh://git@ghc.haskell.org remote set-url --push origin
with a recent version of 'sync-all' which contains [2], then that should be taken care of automatically. HTH, hvr [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/1713 [2]: http://ghc.haskell.org/trac/ghc/changeset/4f43572224b3c8723dc1bf0e886313b0e9...
participants (7)
-
Austin Seipp -
Edward Z. Yang -
Herbert Valerio Riedel -
Jan Stolarek -
Malcolm Wallace -
Simon Marlow -
Simon Peyton-Jones