On Mon, Jan 10, 2011 at 11:19:23AM +, Simon Marlow wrote:
> It's time to consider again whether we should migrate GHC development
> from darcs to (probably) git.
The Boost project has been having similar discussions about when, how
and if to migrate to Git, together with discussions on wheth
On 25 January 2011 09:35, Lars Viklund wrote:
> A subtree seems to be a way of getting the
> contents of a branch merged at a non-root location. It might be a
> relevant read and something to evaluate.
There is also the git-subtree project
(https://github.com/apenwarr/git-subtree). They explain t
On Mon, Jan 10, 2011 at 06:22:03PM -0600, David Peixotto wrote:
> Another possible advantage to git would be its support for submodules[1]. If
> we made the switch to git for all the repositories that GHC uses, then we
> could set them up as submodules. The advantage of submodules is that the GHC
On 17/01/2011 14:08, r...@cse.unsw.edu.au wrote:
On Mon, January 17, 2011 11:08 pm, Simon Marlow wrote:
So, we've decided to try switching to git.
That's very sad!
The changeover will be
staged: first we'll switch the GHC repository, and if all goes well
we'll switch the libraries and other
On Mon, January 17, 2011 11:08 pm, Simon Marlow wrote:
>
> So, we've decided to try switching to git.
That's very sad!
> The changeover will be
> staged: first we'll switch the GHC repository, and if all goes well
> we'll switch the libraries and other sub-repositories. This means we can
> exper
Thanks to everyone who responded on this thread! It's great to see so
much feedback.
Of the people who responded, most were in favour of a switch to git,
with a few notable exceptions. Here at GHC HQ, I'm slightly in favour
of switching while Ian and Simon PJ are agnostic.
So, we've decided
On 13/01/2011 19:11, Brian Bloniarz wrote:
On 01/13/2011 12:49 AM, Simon Marlow wrote:
I spent quite some time yesterday playing with submodules to see if they
would work for GHC. I'm fairly sure there are no fundamental reasons that
we couldn't use them, but there are enough gotchas to put me
On 01/13/2011 12:49 AM, Simon Marlow wrote:
> I spent quite some time yesterday playing with submodules to see if they
> would work for GHC. I'm fairly sure there are no fundamental reasons that
> we couldn't use them, but there are enough gotchas to put me off. I wrote
> down what I discovered he
On 12 January 2011 22:13, Claus Reinke wrote:
>> You can emulate darcs's patch re-ordering in git if you put each
>> independent sequence of patches on a separate branch. Then you can
>> re-merge the branches in whatever order you want. This is a fairly
>> common git workflow.
>
> What happens aft
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
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
You have to use sync-all instead of darcs-all, but the syntax is the
On 13 January 2011 08:54, Roman Leshchinskiy wrote:
> On 12 Jan 2011, at 23:31, "Edward Z. Yang" wrote:
>
>> Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
>>> How would we get the current functionality of darcs-all pull? Is it even
>>> possible?
>>
>> Here is the
On 12 Jan 2011, at 23:31, "Edward Z. Yang" wrote:
> Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
>> How would we get the current functionality of darcs-all pull? Is it even
>> possible?
>
> Here is the rebase-y workflow.
Thank you making things clearer!
>>
>
On 12/01/2011 22:22, Iavor Diatchki wrote:
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy mailto:r...@cse.unsw.edu.au>> wrote:
On 12/01/2011, at 09:22, Simon Marlow wrote:
> On 11/01/2011 23:11, Roman Leshchinskiy wrote:
>>
>> A quick look at the docs seems to i
Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
> How would we get the current functionality of darcs-all pull? Is it even
> possible?
Here is the rebase-y workflow. Untested, so I might have gotten one or two
details wrong.
> Suppose I want to hack on GHC and base
On 12/01/2011, at 22:22, Iavor Diatchki wrote:
> When you issue the command "git submodule update", you are telling git to
> advance the sub-module repo to the "expected version" (i.e., where the
> pointer points to). The reason this does not happen automatically is that
> you might have also
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace wrote:
> As another non-GHC contributor, my opinion should probably also count for
> little, but my experience with git has been poor.
>
> I have used git daily in my job for the last year. Like Simon PJ, I
> struggle to understand the underlying m
You can emulate darcs's patch re-ordering in git if you put each
independent sequence of patches on a separate branch. Then you can
re-merge the branches in whatever order you want. This is a fairly
common git workflow.
What happens after the merges? Does one maintain the branches
somehow, or do
We can't even do this reliably with darcs. Several times I've tried to
unpull one of Simon's patches to work around a bug, and the dependencies
end up being more than just the textual dependencies. Then I have to
fall back to unpulling by date, which is what git would do. And then
sometimes
* Simon Marlow:
> Thanks for this. I distilled your example into a shell script that
> uses git, and demonstrates that git gets the merge wrong:
>
> http://hpaste.org/42953/git_mismerge
>
> Still, git could get this merge right, it just doesn't (I know there
> are more complex cases that would
On 12/01/2011, at 09:22, Simon Marlow wrote:
> On 11/01/2011 23:11, Roman Leshchinskiy wrote:
>>
>> A quick look at the docs seems to indicate that we'd need to do
>>
>> git pull
>> git submodule update
>>
>> which doesn't look like a win over darcs-all. Also, I completely fail to
>> understan
The main advantages to darcs are that it can manipulate the sequence of
patches better than git.
The main advantage of git is that every version is accurately named. If
two people have a commit with a given hash, they will have exactly the
same files and history.
I've been wondering about this
On 11/01/2011 19:07, Roman Leshchinskiy wrote:
On 11/01/2011, at 16:14, Tony Finch wrote:
On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
It also seems to make finding buggy patches rather hard.
Have a look at `git bisect`.
I'm aware of git bisect. It doesn't do what I want. I usually have
On 11/01/2011 23:11, Roman Leshchinskiy wrote:
On 11/01/2011, at 22:20, Simon Marlow wrote:
On 11/01/11 21:57, Roman Leshchinskiy wrote:
IMO, darcs-all works pretty well. I don't think I ever really had
problems with missing library patches.
I often see problems where someone has done 'darcs
On 11/01/2011, at 22:20, Simon Marlow wrote:
> On 11/01/11 21:57, Roman Leshchinskiy wrote:
>> IMO, darcs-all works pretty well. I don't think I ever really had
>> problems with missing library patches.
>
> I often see problems where someone has done 'darcs pull' rather than
> './darcs-all pull'
On 11/01/11 21:57, Roman Leshchinskiy wrote:
On 11/01/2011, at 21:41, Iavor Diatchki wrote:
If GHC and the libraries on which it depends were in git (migrated,
or mirrored), then we could use git sub-modules to track the
dependencies between changes to GHC and changes to the libraries.
Roughly
On 11/01/2011, at 21:41, Iavor Diatchki wrote:
> If GHC and the libraries on which it depends were in git (migrated, or
> mirrored), then we could use git sub-modules to track the dependencies
> between changes to GHC and changes to the libraries.
>
> Roughly, the workflow would be like th
On 11 January 2011 19:07, Roman Leshchinskiy wrote:
> On 11/01/2011, at 16:14, Tony Finch wrote:
>
>> On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
>>>
>>> It also seems to make finding buggy patches rather hard.
>>
>> Have a look at `git bisect`.
>
> I'm aware of git bisect. It doesn't do what I
On 11/01/2011, at 16:14, Tony Finch wrote:
> On Mon, 10 Jan 2011, Roman Leshchinskiy wrote:
>>
>> It also seems to make finding buggy patches rather hard.
>
> Have a look at `git bisect`.
I'm aware of git bisect. It doesn't do what I want. I usually have a pretty
good idea of which patch(es) m
On Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow wrote:
> It's time to consider again whether we should migrate GHC development from
> darcs to (probably) git.
>
> From our perspective at GHC HQ, the biggest problem that we would hope to
> solve by switching is that darcs makes branching and merging
On 11/01/2011 00:36, rocon...@theorem.ca wrote:
On Mon, 10 Jan 2011, Simon Marlow wrote:
It's time to consider again whether we should migrate GHC development
from darcs to (probably) git.
From our perspective at GHC HQ, the biggest problem that we would hope
to solve by switching is that darc
I agree with Roman's position. I would prefer to stay with darcs (it has its
advantages and disadvantages, but has definitely been improving much in the
past).
In any case, all of GHC including all dependencies must be available and
patchable with a *single* VCS. Mixing VCS' will lead to madn
On 10 January 2011 22:19, Simon Marlow wrote:
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
I would really li
On Jan 10, 2011, at 5:19 AM, Simon Marlow wrote:
>
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
+1 for mo
I just want to point out that since the last discussion we collected
some migration advice at
http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Some of it may be untested (or wrong), but it should be a good starting point.
On 10 January 2011 22:15, Neil Mitchell wrote:
>> As another non-
> As another non-GHC contributor, my opinion should probably also count for
> little, but my experience with git has been poor.
>
> I have used git daily in my job for the last year. Like Simon PJ, I
> struggle to understand the underlying model of git, despite reading quite a
> few tutorials. I
On Mon, Jan 10, 2011 at 5:34 AM, Pavel Perikov wrote:
> Please please consider Mercurial if migration from darcs is inevitable :)
>
For what it's worth, Mercurial generally interoperates quite well with git
and github, using the hg-git plugin. As a longtime Mercurial user and an
occasional GHC c
On 10/01/2011, at 13:27, Simon Marlow wrote:
> On 10/01/2011 13:02, Max Bolingbroke wrote:
>> However, I remember the last time this came up there were some issues
>> that might make migration painful. From the top of my head:
>>
>> 1) Some people expressed concern that they would have to use two
On 10 Jan 2011, at 14:02, Gregory Collins wrote:
+1. I don't have a lot of skin in this particular game (I'm not
currently a GHC contributor and am unlikely to become one in the near
future), but I can offer some anecdotal evidence:
As another non-GHC contributor, my opinion should probably als
On Mon, Jan 10, 2011 at 5:08 PM, Pavel Perikov wrote:
> Probably most valuable are the opinions of GHC development team of course :)
> Git really seem to be more popular, Mercurial just seem more streamlined to
> me :)
Their preference if of course very important, but they partly wanted
to make
I'd be for a move, but haven't contributed much lately. I use Git for
all my personal projects, so I consider Git to be useful. I
personally find sending patches via Git to be harder than with Darcs,
but if we use Github the pull-request-based model should work well.
I used Git on Windows two ye
On Mon, Jan 10, 2011 at 2:43 PM, Pavel Perikov wrote:
>
> On 10.01.2011, at 16:40, Johan Tibell wrote:
>> While Mercurial is a fine choice, I think there are more Haskellers
>> that use Git than Mercurial. Probably because GitHub is such an
>> awesome service.
>
> Interesting. It will be great to
I fully support this (especially if it lived on github), but we should
probably sort the top contributors to GHC in the past year or so and
consider their opinions on the matter in that order :) I certainly would not
be on that list. A git(hub)-based workflow would however facilitate any
minor cont
On Mon, Jan 10, 2011 at 2:38 PM, Johan Tibell wrote:
>> Ultimately I'm quite concerned with keeping GHC HQ happy (as you guys
>> do the lions share of the work!). I feel we should only make the
>> switch if the most frequent committers (i.e. Simon, Simon and Ian) are
>> *totally happy* with it and
On Mon, Jan 10, 2011 at 01:27:17PM +, Simon Marlow wrote:
> On 10/01/2011 13:02, Max Bolingbroke wrote:
>> 2) There was also concern that Git isn't so great on Windows. I have
>> heard that this is less of an issue now, but I never personally
>> suffered from any problems, so can't be sure. (FW
On Mon, Jan 10, 2011 at 2:34 PM, Pavel Perikov wrote:
> Please please consider Mercurial if migration from darcs is inevitable :)
While Mercurial is a fine choice, I think there are more Haskellers
that use Git than Mercurial. Probably because GitHub is such an
awesome service.
Johan
__
On Mon, Jan 10, 2011 at 2:02 PM, Max Bolingbroke
wrote:
> Naturally other workflows are possible and I'm sure other list members
> will chime in with their own favourites :-)
Here's the flow I use:
http://nvie.com/posts/a-successful-git-branching-model/
with the exception of having the master b
On Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow wrote:
> We're intrested in opinions from both active and potential GHC
> developers/contributors. Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
I would a
On 10/01/2011 13:02, Max Bolingbroke wrote:
On 10 January 2011 11:19, Simon Marlow wrote:
Let us know what you think - would this make life
harder or easier for you? Would it make you less likely or more likely to
contribute?
Well, as a sometime-contributor I would certainly be happier hacki
On 10 January 2011 11:19, Simon Marlow wrote:
> Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
Well, as a sometime-contributor I would certainly be happier hacking
on GHC if it were git based. When worki
It's time to consider again whether we should migrate GHC development
from darcs to (probably) git.
From our perspective at GHC HQ, the biggest problem that we would hope
to solve by switching is that darcs makes branching and merging very
difficult for us. We have a few branches of HEAD that
51 matches
Mail list logo
