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
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 dan...@gmail.com wrote:
In my one serious attempt to use git for one of my own projects, some
seemingly-innocuous operation deleted a
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
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 25 January 2011 09:35, Lars Viklund z...@acc.umu.se 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).
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
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
experiment
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
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 link
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 12/01/2011 22:22, Iavor Diatchki wrote:
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
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
On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu 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 13 January 2011 08:54, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu 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
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
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 Thu, Jan 13, 2011 at 4:03 PM, Simon Marlow marlo...@gmail.com 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
On 13 January 2011 15:30, Johan Tibell johan.tib...@gmail.com 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
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
On 12 January 2011 22:13, Claus Reinke claus.rei...@talk21.com 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.
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
If we
On Thu, Jan 13 2011, Benedict Eastaugh wrote:
On 13 January 2011 15:30, Johan Tibell johan.tib...@gmail.com 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.
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 here:
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
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
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
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),
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
understand what git
* 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 be
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
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
Hello,
On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy
r...@cse.unsw.edu.auwrote:
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
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace malcolm.wall...@me.com 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
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 made
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 1/12/11 5:34 PM, Tim Chevalier wrote:
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallacemalcolm.wall...@me.com 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
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
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
On Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow marlo...@gmail.com 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
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.finch d...@dotat.at http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5,
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) might
On 11 January 2011 19:07, Roman Leshchinskiy r...@cse.unsw.edu.au 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
Hello,
On Mon, Jan 10, 2011 at 12:49 PM, Roman Leshchinskiy
r...@cse.unsw.edu.auwrote:
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
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 this:
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 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' and
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 do automatic
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
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
On 10 January 2011 11:19, Simon Marlow marlo...@gmail.com 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
On 10/01/2011 13:02, Max Bolingbroke wrote:
On 10 January 2011 11:19, Simon Marlowmarlo...@gmail.com 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
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 Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow marlo...@gmail.com 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
On Mon, Jan 10, 2011 at 2:02 PM, Max Bolingbroke
batterseapo...@hotmail.com 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
On Mon, Jan 10, 2011 at 2:34 PM, Pavel Perikov peri...@gmail.com 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.
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 ok
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. (FWIW I
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
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 and
On Mon, Jan 10, 2011 at 2:43 PM, Pavel Perikov peri...@gmail.com 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
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
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
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
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
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 Mon, Jan 10, 2011 at 5:25 PM, Nils Anders Danielsson
n...@cs.nott.ac.uk 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
To: 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 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
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
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
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 how
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
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 work
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 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 Mon, Jan 10, 2011 at 5:34 AM, Pavel Perikov peri...@gmail.com 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
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 have
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
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 aw...@galois.com wrote:
On 01/10/2011 08:52 AM, Malcolm Wallace wrote:
If I were considering
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 ndmitch...@gmail.com
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 moving
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
On 10 January 2011 22:19, Simon Marlow marlo...@gmail.com 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
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
-boun...@haskell.org
Date: Tue, 11 Jan 2011 15:01:43
To: GHCcvs-...@haskell.org; GHC Listglasgow-haskell-users@haskell.org
Cc: Simon Marlowmarlo...@gmail.com
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
84 matches
Mail list logo
