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 me and
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 example, what doe
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
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). I am sending the lin
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 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 than it used to be.
>
> http://progit.o
On Thu, Jan 13 2011, Simon Marlow wrote:
> I discovered that Google have this tool called "repo" which is their
> darcs-all for the Android source tree. That might be worth looking at
> as an alternative in the future:
>
> https://sites.google.com/a/android.com/opensource/download/using-repo
>
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
Hi,
Just as a point of information, the following rules can help avoid some of
the gotchas:
- Treat submodules are read-only (i.e., don't make commits there). The
reason for this is that a submodule is usually not on a branch, and so
making a commit would result in a detached head.
- When you pul
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, GitHub are now us
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 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 is updated to
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
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 w
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
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
> >>
> >> git pull
> >> git submodule update
> >>
> >>
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
On Wed, 12 Jan 2011, Claus Reinke wrote:
>
> In my understanding, the unorderedness of patch history in darcs is
> there to make distributed repos easier (fewer constraints: same set of
> patches, but not same order; can mix local commits and pulls from
> various repos, no need for a central repo),
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 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
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
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
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
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, although I
did ho
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 difficult
f
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-
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!"
:)
On Mon, Jan 10, 2011 at 5:32 PM, Adam Wick wrote:
> On 01/10/2011 08:52 AM, Malcolm Wallace wrote:
>
>> If I were considering contributin
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 wheth
> 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 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 problem for me if GHC
> were to swi
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
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.
M
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 well it's going to 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 migrate GHC developm
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 my own experience
with so
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
: Simon Marlow
Cc: GHC CVS list; glasgow-haskell-users@haskell.org
Subject: Re: RFC: migrating to git
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
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-haskell-users@
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
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 months and d
On 10.01.2011, at 18:59, Johan Tibell wrote:
> I've just observed what other Haskellers talk about
> and where I usually find projects (when they are not in Darcs). We
> could probably pull the numbers of Hackage.
Probably most valuable are the opinions of GHC development team of course :)
Git
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
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 year ago for 3 months a
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 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 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 see any numbers (really, just curious).
bitbucket seems to be o
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
Please please consider Mercurial if migration from darcs is inevitable :)
P.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
86 matches
Mail list logo
