Done.
On 31 October 2011 10:01, Dimitrios Vytiniotis wrote:
>
> Hi everyone, it would be useful for someone to reproduce the instructions or
> add the link:
> http://help.github.com/set-your-user-name-email-and-github-token/
> somewhere in the developer wiki. (where?) I've forgotten to
On 4 August 2011 09:06, Ben Lippmeier wrote:
>
> All,
> Can someone please explain how to pull patches into the GHC trees when you've
> got branches? I was following the instructions on the GHC wiki. I've got the
> 7.2 branch but I can't work out how to pull new patches into it.
>
>
> desire:ghc
+1 to this proposal.
Edward
Excerpts from Max Bolingbroke's message of Tue Aug 02 10:01:44 -0400 2011:
> Hi GHCers,
>
> As far as I can tell, darcs.haskell.org does not use fast HTTP cloning
> for the GHC git repository. This means that:
> 1. Cloning the repository over HTTP taking ~7 minutes
Simon Marlow:
> On 09/05/2011 21:04, Roman Leshchinskiy wrote:
>> As usual, I'm too stupid
>> to understand the git docs. This all *is* quite complicated.
>
> I am also too stupid to understand the git docs. We should start a club!
> What I know about git I've mostly discovered by experimentati
On 10/05/2011 11:11, Roman Leshchinskiy wrote:
Simon Marlow wrote:
I'm not sure exactly what it means to rebase two branches "in sync". I
know that if you rebase a branch and the target of the rebase already has
(some of) the patches that you are rebasing, then git will drop them
during the re
Simon Marlow wrote:
>
> I'm not sure exactly what it means to rebase two branches "in sync". I
> know that if you rebase a branch and the target of the rebase already has
> (some of) the patches that you are rebasing, then git will drop them
> during the rebase.
Ah, that's good to know. Thanks! S
On 09/05/2011 21:04, Roman Leshchinskiy wrote:
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:
Simon Marlow:
- you develop in your working tree and commit patches there. At
this point it's completely safe to rebase - the patches are only
in one place.
- you pull the patches into the
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:
> Simon Marlow:
>>
>> - you develop in your working tree and commit patches there. At
>> this point it's completely safe to rebase - the patches are only
>> in one place.
>>
>> - you pull the patches into the validate tree (you just rebas
Simon Marlow:
> Some of us are using rebase to avoid merge commits where possible, but it is
> quite easy to get into a mess so I hesitate to suggest rebase as our
> recommended workflow. Ordinary merging works fine modulo the noisy merge
> commits, so I'm happy for people to just do 'git pull'
On 09/05/2011 05:48, Manuel M T Chakravarty wrote:
Simon Peyton-Jones:
It's a long message and I don't understand it.
Suppose we have * A branch * Shared between several people *
Long-lived (weeks not day) how should we manage it?
It *must* be possible to merge fixes from the master into the
b
Simon Peyton-Jones:
> It's a long message and I don't understand it.
>
> Suppose we have
> * A branch
> * Shared between several people
> * Long-lived (weeks not day)
> how should we manage it?
>
> It *must* be possible to merge fixes from the master into the branch. Doing
> so, and then valida
On Fri, May 06, 2011 at 01:50:29PM -0700, David Terei wrote:
> The way I work which I think works well is:
This seems to me like a lot of effort, and a lot of potential for people
to get in a muddle, just to avoid some harmless merge commits.
Thanks
Ian
The way I work which I think works well is:
1) While developing, do whatever you feel like in your branch. So lots
of merge commits are fine since as pointed out, rebasing can make
multi party collaboration a little difficult at times.
2) When a point is reached where you want to push some work u
On 05/06/11 05:15, Simon Peyton-Jones wrote:
So I think merging the master onto the branch must be done regularly not as a
big bang at the end.
If someone would like to write a duffers guide describing how to do that, I'm
happy to follow it. But the only way I understand is to merge master on
Simon Marlow:
> On 06/05/11 02:05, Manuel M T Chakravarty wrote:
>> There seems to be quite a bit of merging from master into branches
>> going on in the GHC repos at the moment. This isn't necessarily a
>> good way of using Git as Linus explains in this message:
>>
>> http://www.mail-archive.com
It's a long message and I don't understand it.
Suppose we have
* A branch
* Shared between several people
* Long-lived (weeks not day)
how should we manage it?
It *must* be possible to merge fixes from the master into the branch. Doing
so, and then validating, is essential because (as we have p
On 06/05/11 02:05, Manuel M T Chakravarty wrote:
There seems to be quite a bit of merging from master into branches
going on in the GHC repos at the moment. This isn't necessarily a
good way of using Git as Linus explains in this message:
http://www.mail-archive.com/dri-devel@lists.sourceforge.
Hi Manuel,
What is then the right way to do things? It is not clear to me from Linus's
email. Consider the ghc-generics branch scenario:
- A couple of repos are branched (compiler, ghc-prim, and others), but not
all. These other repos are just using the "master" branch;
- Two people work on it sep
On Fri, Apr 08, 2011 at 11:19:25AM +, Simon Peyton-Jones wrote:
> ls -l libraries/dph/ghc-packages libraries/dph/ghc-packages2
> -rw-r--r-- 1 simonpj Administrators 72 Apr 4 10:48 libraries/dph/ghc-packages
> -rw-r--r-- 1 simonpj Administrators 78 Apr 4 10:48
> libraries/dph/ghc-packages2
On Fri, Apr 08, 2011 at 10:40:12AM +, Simon Peyton-Jones wrote:
> | > sh validate --no-clean
> | > make[1]: *** No rule to make target `libraries/dph/dph-common/ghc.mk',
> needed
> | by `libraries/dph/dph-par/dph-par.cabal'. Stop.
> |
> | Hmm, boot should have made libraries/dph/dph-com
| > sh validate --no-clean
| > make[1]: *** No rule to make target `libraries/dph/dph-common/ghc.mk',
needed
| by `libraries/dph/dph-par/dph-par.cabal'. Stop.
|
| Hmm, boot should have made libraries/dph/dph-common/ghc.mk
|
| Does the full "sh validate" work?
No. See below. I'm a bit
On Wed, Apr 06, 2011 at 09:24:18AM +, Simon Peyton-Jones wrote:
> | Well, the good news is that this looks unrelated to git: The base
> | package changed recently to use AC_COMPUTE_INT.
> |
> | If you change "AC_COMPUTE_INT" to "FP_COMPUTE_INT" on lines 126, 133,
> | 136, 139, 155, 158 of
| Well, the good news is that this looks unrelated to git: The base
| package changed recently to use AC_COMPUTE_INT.
|
| If you change "AC_COMPUTE_INT" to "FP_COMPUTE_INT" on lines 126, 133,
| 136, 139, 155, 158 of libraries/base/aclocal.m4 (but not the
| "_AC_COMPUTE_INT" on line 11), does
>
> Cloning is dramatically faster with Git's own protocol.
>
Since v1.6.6, with some amount of setup on the server side, http is almost
as fast as git protocol: http://progit.org/2010/03/04/smart-http.html
> Cvs-ghc mailing list
> Cvs-ghc@haskell.org
> http://www.haskell.org/mailman/listinfo/cv
Excerpts from Simon Peyton-Jones's message of Mon Apr 04 04:50:21 -0400 2011:
> Doing a 'git clone' of the main GHC repository is pretty slow (ten minutes
> plus), presumably because it fetches everything. sync-all takes another
> twenty minutes
>
> Would it be faster using git's own protocol rat
On Sun, Apr 03, 2011 at 06:54:43PM +0100, Max Bolingbroke wrote:
>
> It then worked perfectly when I pushed from my machine. So I guess you
> should advise everyone who is going to commit to d.h.o to ssh to
> github.com first and accept their host key, or else create a
> /etc/ssh/ssh_known_hosts f
On 3 April 2011 13:48, Ian Lynagh wrote:
> It should work for you. What error are you seeing?
The error is not what I thought:
"""
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 348 bytes, done.
T
On Sun, Apr 03, 2011 at 12:59:08PM +0100, Max Bolingbroke wrote:
>
> You should probably stop the post-receive hook from pushing to Github
> if it executes in the context of a user without permissions for the
> private key, though. I'm getting an (otherwise harmless) error message
> about this whe
On 3 April 2011 00:52, Ian Lynagh wrote:
>
> There's now a github mirror here:
> https://github.com/ghc/ghc
>
> I'll add mirrors of the other repos soon.
Great, thanks.
You should probably stop the post-receive hook from pushing to Github
if it executes in the context of a user without permis
On Sun, Apr 3, 2011 at 1:52 AM, Ian Lynagh wrote:
>
> There's now a github mirror here:
> https://github.com/ghc/ghc
>
> I'll add mirrors of the other repos soon.
Nice!
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/list
There's now a github mirror here:
https://github.com/ghc/ghc
I'll add mirrors of the other repos soon.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Fri, Apr 01, 2011 at 05:33:57PM +0100, Ian Lynagh wrote:
>
> The git migration is now more-or-less complete.
Ooops, a handful of the repos weren't quite right. If you already have a
git checkout, please do this to get the right ones:
rm -rf libraries/Cabal
rm -rf libraries/bytestring
rm -rf l
On Fri, 1 Apr 2011 17:33:57 +0100
Ian Lynagh wrote:
>
> Hi all,
>
> The git migration is now more-or-less complete.
>
> Instructions for getting a git tree are here:
> http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources
It would also be awesome to update github mirror
On 1 April 2011 22:56, Ian Lynagh wrote:
> On Fri, Apr 01, 2011 at 10:41:01PM +0100, Max Bolingbroke wrote:
>>
>> Did you perhaps not do "git push --tags"?
>
> Ah, I did not! Now done.
Thanks, I see it now.
Others on this list may be interested in a script I wrote (uploaded to
http://hackage.has
On Fri, Apr 01, 2011 at 10:41:01PM +0100, Max Bolingbroke wrote:
>
> Did you perhaps not do "git push --tags"?
Ah, I did not! Now done.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On 1 April 2011 17:33, Ian Lynagh wrote:
> The git migration is now more-or-less complete.
Thanks for your work on this, Ian!
> If you have a branch that you want to merge, then the instructions are
> here:
> http://hackage.haskell.org/trac/ghc/wiki/DarcsToGit
I had trouble following these i
: cvs-ghc@haskell.org
| Subject: Re: Git switchover
|
| Hi Ian,
|
| What does this mean for ghc developers? After the change over should
| we start following these instructions to get ghc head? Will there be
| any period of both darcs and git?
|
| http://hackage.haskell.org/trac/ghc/wiki
Hi Ian,
What does this mean for ghc developers? After the change over should
we start following these instructions to get ghc head? Will there be
any period of both darcs and git?
http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion/Building/GettingTheSources
Also is there an easy way to han
On Sun, Mar 13, 2011 at 07:22:30AM +, Adam Megacz wrote:
>
> It seems that the git mirror of the base package is a few months out of
> date:
We'll be switching to git on Tuesday. We'll make up-to-date git
conversions at that point.
Thanks
Ian
__
On 14/01/2011 02:32, Kazu Yamamoto (山本和彦) wrote:
Hello Simon,
I've made git mirrors of the current GHC HEAD repos (all of them), so
people can try out their workflows with git. Hopefully this should
work:
git clone http://darcs.haskell.org/ghc-git/ghc.git
cd ghc
perl sync-all get
T
On Thu, Jan 13, 2011 at 4:03 PM, Simon Marlow wrote:
> I've made git mirrors of the current GHC HEAD repos (all of them), so people
> can try out their workflows with git.
Poking around in the different repos works for me and is fast. For example:
Find new files in base:
$ cd libraries/base
$ g
On 01/12/11 02:52, Alexander McPhail wrote:
Hi,
I have a couple of branches of ghc off of HEAD.
I found that I had some difficulty _finding_ my patch submissions after
weeks of 'darcs_all pull -a'. And I understand that one complaint is the
need to create 'megapatches'.
How is this flow:
1)
On Tue, Mar 03, 2009 at 05:10:36PM +, Simon Peyton-Jones wrote:
>
> Syncing Git repo.
> Finished applying...
> Waiting for fcntl lock... 1
> Counting objects: 11, done.
> Compressing objects: 100% (6/6), done.
> Writing objects: 100% (6/6), 2.32 KiB, done.
> Total 6 (delta 5), reused 0 (delta
On Thu, Sep 11, 2008 at 07:26:09PM -0700, Tim Chevalier wrote:
>
> error: Unable to append to .git/logs/refs/remotes/github/master:
> Permission denied
Thanks; I've just fixed this one too.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http
On Wed, Sep 10, 2008 at 4:09 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> As far as I can tell from the error, git failed to create a file in
> /home/darcs/git/ghc.git/refs/remotes/github/ on monk, but the
> permissions look fine so I have no idea why that would happen.
>
> It would be interesting t
On Wed, Sep 10, 2008 at 1:17 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> I'm a little worried by the success...
The trickier part is the sync-script, but I use a lock for that and it
will fail (and did so before) if it cannot obtain this lock. Due to
Git's SHA-1 checksums, I'm fairly certain that
Ian Lynagh wrote:
On Wed, Sep 10, 2008 at 11:32:07AM +0200, Thomas Schilling wrote:
I'm not sure. It could be some permission thing as a result of how
the script works that syncs with the Github repo. Github uses ssh key
authentication to identify the user, so we set up a keyfile that
should b
it happened once more today already. but many other pushes did not elicit that
msg
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lynagh
| Sent: 10 September 2008 12:10
| To: cvs-ghc@haskell.org
| Subject: Re: Git problem
|
| On Wed, Sep 10
On Wed, Sep 10, 2008 at 12:09:59PM +0100, Ian Lynagh wrote:
> On Wed, Sep 10, 2008 at 11:32:07AM +0200, Thomas Schilling wrote:
> > I'm not sure. It could be some permission thing as a result of how
> > the script works that syncs with the Github repo. Github uses ssh key
> > authentication to id
On Wed, Sep 10, 2008 at 11:32:07AM +0200, Thomas Schilling wrote:
> I'm not sure. It could be some permission thing as a result of how
> the script works that syncs with the Github repo. Github uses ssh key
> authentication to identify the user, so we set up a keyfile that
> should be used by eve
I'm not sure. It could be some permission thing as a result of how
the script works that syncs with the Github repo. Github uses ssh key
authentication to identify the user, so we set up a keyfile that
should be used by everyone with push access to darcs.h.o. Apparently,
Git creates some files w
51 matches
Mail list logo
