On Tue, 11 Jan 2011, Simon Marlow wrote:
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
I've posted an annotation at
http://hpaste.org/paste/42953/git_mismerge_annotation#p42
On Tue, Jan 11 2011, Roman Leshchinskiy wrote:
> On 11/01/2011, at 22:20, Simon Marlow wrote:
>
>> On 11/01/11 21:57, Roman Leshchinskiy wrote:
>>> This would be useful. Unfortunately, git's rewinding seems rather
>>> crippled compared to darcs.
>>
>> In what way?
>
> Thomas says that it doesn't
Hello Simon,
Have you gotten a chance to look at these two hunks? (see below)
Thanks,
Edward
Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010:
> Ok, I've got a patch that fixes this segfault. In the process I looked
> at all patches to Cg* modules after Nov 2009 and look
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
Hello,
On Mon, Jan 10, 2011 at 12:49 PM, Roman Leshchinskiy
wrote:
> On 10/01/2011, at 13:27, Simon Marlow wrote:
> > It would be a prerequisite to switching that a GHC developer only has to
> use one VCS. So we either migrate dependencies to git, or mirror them in
> GHC-specific git branches.
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, 10 Jan 2011, Roman Leshchinskiy wrote:
>
> It also seems to make finding buggy patches rather hard.
Have a look at `git bisect`.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 L
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
On 10 Jan 2011, at 22:37, Daniel Peebles wrote:
So the basic point seems to be: "if you know how to use a tool, you
don't usually curse and swear when you use it. If you don't, you
tend to swear a lot!"
There is a meta-point though - how easy is it to learn the tool?
Regards,
Malcolm
desugarModule returns a GHC.DesugaredModule
Inside a DesugaredModule is a field dm_core_module :: HscTypes.ModGuts
Inside a ModGuts is a field mg_binds :: [CoreSyn.CoreBind]
And there are your bindings! Does that tell you what you wanted to know?
Simon
PS: When you have it clear, would you like
Simon Marlow wrote:
> The darcs team have been making great strides with performance, but
> conflict handling remains a serious problem. The darcs roadmap
> doesn't show this being fixed in the near future
>
>http://wiki.darcs.net/Roadmap
I've just updated the roadmap for darcs 2.8 (the n
15 matches
Mail list logo