On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote:
> Is the 7.10.2 hvr ppa using this RC?
...it's easy to check, as since 7.10 we embed the Git commit id into the
source-tarball as well as into the generated ghc binary:
$ /opt/ghc/7.10.2/bin/ghc --info | grep Git
,("Project
git-monitor auto-commits all changes to a Git working tree, within a special
branch named "refs/snapshots/refs/heads/". It has no impact on the
Git repository otherwise, and will not effect your real branches.
It has the following features:
- It is designed to be extremely resource
Erik de Castro Lopo wrote:
> Given a GHC git commit hash, is there a way to get the various
> libraries into a state where I can build the GHC version specified
> by the hash?
As suggested by this:
http://hackage.haskell.org/trac/ghc/wiki/Building/GettingT
On Mon, Feb 27, 2012 at 10:37:25AM +1100, Erik de Castro Lopo wrote:
>
> Given a GHC git commit hash, is there a way to get the various
> libraries into a state where I can build the GHC version specified
> by the hash?
No, but if you have a list of nightly builds, e
Hi all,
I am trying to track down a build failure on PowerPC that was
introduced some time this year.
Usually, the easiest way to do this is by using 'git bisect'.
Unfortunately, this doesn't work with the GHC tree since its easy to
go to a GHC revision which is incompatible with
Hi all,
Since we've now switched to git I though I share Linus' notes on
rebasing for those of you who haven't seen them:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
The mail talks about when to use rebase and when
I just noticed that the discussion has been concluded and I was replying to an
old thread. I apologize for the noise.
On Wed, Feb 9, 2011 at 6:56 PM, Dan Knapp wrote:
> In my one serious attempt to use git for one of my own projects, some
> seemingly-innocuous operation deleted a file on
In my one serious attempt to use git for one of my own projects, some
seemingly-innocuous operation deleted a file on me and I lost a couple
hours of work. I agree with the people who have said that git's
documentation and semantics are highly confusing, moreso than darcs's.
For exa
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 dis
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). The
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
On 23 January 2011 00:31, austin seipp wrote:
> or what the current state of dynamic linking on
> windows is.
AFAIK it is meant to work. What I'm not sure about is whether any of
the plugins code will have to be modified to make use of it. I suspect
it won't since IIRC I went through the GHCi sym
(moved into g-h-u mainline to avoid cluttering discussion around new
GHC plans. Anybody who has comments on the plugins work is encouraged
to reply here, not there.)
Neil,
Preemptive TL;DR: I don't quite know, but I'd be willing to work on it.
I seem to remember at the time Max originally did hi
Hi Austin,
The compiler plugins work is a great, and I'd be a likely user. The
original version wasn't supported on Windows, because GHC on Windows
lacked various forms of dynamic linking. Does the current patch you've
prepared work on Windows?
Thanks, Neil
On Sat, Jan 22, 2011 at 10:29 AM, Max
On 21 January 2011 23:59, austin seipp wrote:
> Perhaps Max can
> elaborate on why this design was rejected in favor of the current one,
> so we can see how and where it falls down, and what we really want.
The only reason really is that it added a lot of mechanism. From the
top of my head:
* Pa
To: Simon Peyton-Jones
Cc: Simon Marlow;
glasgow-haskell-users@haskell.org
Subject: Re: Release/git plans
Simon,
On Fri, Jan 21, 2011 at 3:13 AM, Simon Peyton-Jones
wrote:
> Austin
>
> | So, given that 7.2 will be released much earlier than the normal
> | release cycle, is there
7.2 would cause problems merging changes
> | until you cut a new STABLE branch with git, like you said.
>
> I'm sorry I've been slow on this. "Review and apply the plugins patch" is in
> my inbox, but it's been queued up behind too many other things, notably
&g
On 21 January 2011 09:13, Simon Peyton-Jones wrote:
> I'm pretty keen on the whole plugin idea, because it makes the compiler more
> extensible and lowers the barrier to entry. My only reason for delay is that
> I wanted to review the design (as seen by a plug-in author). Once we provide
> i
tly adding dynamic loading and the plugin API, but it's
| arguably adding a 'big' feature for users of GHC to start utilizing,
| and perhaps a release in 7.2 would cause problems merging changes
| until you cut a new STABLE branch with git, like you said.
I'm sorry I've been s
differently.
>
> Either way, I, for one, welcome our new version control overlord.
>
> On Thu, Jan 20, 2011 at 3:09 PM, Isaac Dupree
> wrote:
> > On 01/20/11 11:57, austin seipp wrote:
> >>>
> >>> The GHC git repo that
> >>> we'll be using is
pp wrote:
>>>
>>> The GHC git repo that
>>> we'll be using is here:
>>>
>>> http://darcs.haskell.org/ghc.git
>>
>> This is an incredibly minor note in my opinion (that was brought up
>> before IIRC) but, isn't it a little s
On 01/20/11 11:57, austin seipp wrote:
The GHC git repo that
we'll be using is here:
http://darcs.haskell.org/ghc.git
This is an incredibly minor note in my opinion (that was brought up
before IIRC) but, isn't it a little strange for ghc's git repository
to exist on darcs.h
On 20 January 2011 16:57, austin seipp wrote:
> It would be nice to have this in GHC 7.2, but I was thinking of
> eventually extending the scope of compiler plugins to allow users to
> write Cmm optimisations as well.
This would be particularly cool because Cmm optimisations in the new
Hoopl fram
s darcs, but the HEAD will be git, so the longer
> this situation persists the more difficult it is to merge changes.
> Hence we want to fork a new STABLE branch as soon as possible.
>
> - one of the fixes we need to make soon, to fix equality superclasses,
> is too large a
As promised, here are our plans for forthcoming GHC releases and the git
switchover:
- do a 7.0.2 RC as soon as possible, followed shortly by a release.
Currently blocking this is a problem with Cabal that shows up on
OS X 10.6, we hope to have this resolved soon.
- switch the GHC repo
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 swit
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 s
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.
Hello,
thanks for this Simon! I've ported my work on the type-naturals feature as
a git branch, and everything seems to be working as expected so far. I've
put my modified repos at http://code.galois.com/cgi-bin/gitweb (their names
all start with the "type-naturals" prefix
none, i.e. use subrepos consistently
or not at all. Some of these subrepos are developed quite actively and
concurrently with GHC, particularly base. Indeed if it were the case
that we were just consumers of an upstream repo, then I would agree with
you that subrepos are a clear win.
To
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-al
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
Thank you for th
category "the rest of libraries (e.g. filepath, containers, bytestring,
editline)"
i.e. things that you expect to passively track and occasionally
pick up new patches from. What's the argument against using
subrepos for those?
To me, the major gotcha is "git submodule update"
On Thu, Jan 13 2011, Benedict Eastaugh wrote:
> On 13 January 2011 15:30, Johan Tibell wrote:
>> We should set up a git daemon at some point as it's much more
>> efficient that pulling over HTTP.
>
> As of version 1.6.6, Git is much more efficient over HTTP th
ource/download/using-repo
>
> If we go with git, I suggest we stick with sync-all for the time being
> and think about either submodules or repo as possibilities for the
> future.
The author of Gerrit/Repo has stated that he intends to have better
integration between repo and git submodul
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 g
n you pull (or change branches) use "git submodule update" to move the
submodules to their correct versions (yes, it's annoying that one has to do
that).
- Changes to a sub-module should be done in a separate repo (not GHC's
submodule). This is where you switch "hats" a
On 13 January 2011 15:30, Johan Tibell wrote:
> We should set up a git daemon at some point as it's much more
> efficient that pulling over HTTP.
As of version 1.6.6, Git is much more efficient over HTTP than it used to be.
http://progit.org/2010/03/04/smart-http.html
In fact, Git
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 lib
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 i
On Wed, 12 Jan 2011, Claus Reinke wrote:
>
> What happens after the merges? Does one maintain the branches
> somehow, or does one lose the (in-)dependency information?
Remember that a branch in git is just a name for a point in the revision
graph. When you commit to a branch the name i
ven
>>> possible?
>>
>> Here is the rebase-y workflow.
>
> Thank you making things clearer!
>
>>>
>> # pull the latest patches for GHC, and sticks your patchset on top
>> git pull --rebase
>> #
>> # register any new submodules
ow.
Thank you making things clearer!
>>
> # pull the latest patches for GHC, and sticks your patchset on top
> git pull --rebase
> #
> # register any new submodules (if any)
> git submodule init
> # make your submodules reflect the latest version GHC has
> git submodule updat
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 understand what git submodule update does. It doesn't se
On 1/12/11 5:34 PM, Tim Chevalier wrote:
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace wrote:
If I were considering contributing minor patches to a project, the use of
git would probably not deter me too much - I can cope with the simple stuff.
But if I wanted more major involvement, git
ack on GHC and base (base is a submodule of GHC). For
> this, I want to:
>
> - pull the latest patches to both GHC and base
# pull the latest patches for GHC, and sticks your patchset on top
git pull --rebase
#
# register any new submodules (if any)
git submodule init
# make your submod
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 i
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
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy
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 indicate that we'd need to do
> >
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
someho
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
* 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 mor
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 loo
a central repo),
Apart from variable patch ordering all of that is true of all DVCSs.
> and because darcs has a causal rather than a temporal view of patch
> history (which patch depends on which other patches, instead of which
> patch came first).
You can emulate darcs's patch
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
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.
done 'darcs pull' rather than
'./darcs-all pull' and ended up with a weird compilation error as a result. If
we could eliminate this source of errors, it would be a major win.
A quick look at the docs seems to indicate that we'd need to do
git pull
git submodule update
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_annot
t; In what way?
>
> Thomas says that it doesn't do automatic dependency tracking which
> looks like a huge weakness to me. Personally, I haven't been able to
> successfully unpull non-consecutive chunks of patches with git so far
> but I only tried 2 or 3 times before
27; rather than
> './darcs-all pull' and ended up with a weird compilation error as a result.
> If we could eliminate this source of errors, it would be a major win.
A quick look at the docs seems to indicate that we'd need to do
git pull
git submodule update
which doesn&
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
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 workflo
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-specif
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`.
>
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 pret
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, OCCASION
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
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
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
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
askell.org
Date: Tue, 11 Jan 2011 15:01:43
To: GHC; GHC List
Cc: Simon Marlow
Subject: Re: RFC: migrating to git
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 o
;>> 1) Some people expressed concern that they would have to use two
>>> revision control systems to work on GHC, because not all GHC
>>> dependencies would be git-based.
>>
>> It would be a prerequisite to switching that a GHC developer only has to use
>&
?
I would really like GHC to move to git. I find darcs pretty annoying
when working in a branch and the performance still just isn't good
enough (e.g can't use 'annotate'). I've been a big fan of git from
pretty much as soon as I started using it, its interface is badly
des
I'm inclined to vote +1 for a move to git. JP and I seem to collaborate just
fine using github for EclipseFP and scion, FWIW. I tend to develop on ad hoc
branches before I merge changes back onto the master branch.
I can't say that either of us have run into significant problems, alth
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 darcs makes branching and merging very diff
contribute?
+1 for moving to git
As an infrequent contributor I would welcome the move to git. I think the
biggest advantage from my perspective would be enabling branches which I have
avoided up to now because of the painful process I hear about from others.
Another possible advantage to git
er 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
&g
;
>> If I were considering contributing minor patches to a project, the use of
>> git would probably not deter me too much - I can cope with the simple stuff.
>> But if I wanted more major involvement, git would definitely cause me to
>> think twice about whether to bother.
>>
On 01/10/2011 08:52 AM, Malcolm Wallace wrote:
If I were considering contributing minor patches to a project, the use
of git would probably not deter me too much - I can cope with the
simple stuff. But if I wanted more major involvement, git would
definitely cause me to think twice about
> 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
>
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
occ
On 11.01.2011, at 0:29, Bryan O'Sullivan wrote:
>
> 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 contributor, it wouldn't be a practical probl
that they would have to use two
>> revision control systems to work on GHC, because not all GHC
>> dependencies would be git-based.
>
> 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 the
Hello,
I have been working on a GHC branch for the last few months and, for me,
switching to git would be a win because I find it quite difficult to keep my
branch and HEAD synchronized. I allocate about a day, probably about once a
month, to redo my repository so that it is in sync with HEAD
On Mon, Jan 10, 2011 at 01:27:17PM +, 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.
I think it's hard to know how w
I am very interested in contributing to GHC, though the state of
development with darcs makes me hesitate. A switch to git would make
contribution to the project much easier.
--trevor
On 01/10/2011 03:19 AM, Simon Marlow wrote:
> It's time to consider again whether we should mig
On Mon, Jan 10, 2011 at 01:27:17PM +, Simon Marlow wrote:
>
> I don't think the dependencies get very deep in most cases, and my
> impression is that we often don't want to pull the dependencies anyway,
> so darcs forces us to merge the patch manually (Ian would be able to say
> for sure
On Mon, Jan 10, 2011 at 12:47:43PM -0500, Norman Ramsey wrote:
>
> My workflow has never involved much cherry-picking, and I tried
> revising history ('rebasing') once and didn't like it. But I use
> git's "cheap branching and merging" workflow *very* heavily.
Do you mean you've used this to do
> It's time to consider again whether we should migrate GHC development
> from darcs to (probably) git.
I'd be thrilled to see GHC migrate to git, and I'd be much more likely
to make new contributions to the back end.
The rest of this email contains observations about m
d 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 have a high failure rate with attempting
anything
As everyone has been saying, the primary issue is the workflow of the main
contributors and the cost of the transition.
However, I made the transition to Git and GitHub earlier this year and that
initial investment has been repaid handsomely (it’s the first system I have
felt truly
On Mon, Jan 10, 2011 at 5:25 PM, Nils Anders Danielsson
wrote:
> Even if GitHub is used you should probably arrange some other kind of
> backup solution, because GitHub reserves the right to delete your
> repository "for any reason at any time" (http://help.github.com/terms/).
If that would ever
On 2011-01-10 16:39, Daniel Peebles wrote:
(especially if it lived on github)
Even if GitHub is used you should probably arrange some other kind of
backup solution, because GitHub reserves the right to delete your
repository "for any reason at any time" (http://help.github.com/terms/).
--
/NAD
On 10.01.2011, at 19:29, Johan Tibell wrote:
> I'm
> not trying to get into a Git vs Mercurial argument here. I have more
> important things to do, like writing code. :)
Absolutely true :)
___
Glasgow-haskell-users mailing list
Glasgow
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 wante
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 W
Am 10.01.2011 14:02, schrieb Max Bolingbroke:
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. (FWIW I used Git on
Windows industrially ~1 year ago for 3
team of course :)
Git really seem to be more popular, Mercurial just seem more streamlined to me
:)
P.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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.
>
> In
On Mon, Jan 10 2011, 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. (FWIW I used Git on
> Windows industrially ~1
1 - 100 of 120 matches
Mail list logo
