Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hello,
Thanks for all your responses (and the --skip-conflicts tip)! I use
git for a lot of my development, so I was hoping that I was just
experiencing "culture shock" and simply doing things with the wrong
mind-set. Given the responses though, it sounds like this is a well
known problem with darcs with no obvious solution. For me, switching
GHC to git would certainly be a win.
In terms of the future of darcs, while better tools for managing
rebasing would certainly be useful, I am not confident that any
solution based on mutation (i.e., "rewriting history" by rebasing/
amend-recoding) would work well in a distributed environment due to
the difficulty of sharing these changes---it seems to require some
sort of "higher order" version control where you have to keep track of
the changes to the changes :-)
In the context of git, I only brought up "rebasing" because it seemed
like the closest concept to what I was doing with darcs. If GHC was
to switch to git, I think that we should certainly use git's ordinary
merge model to keep track of history.
-Iavor
PS for VCS folks: I think that an interesting idea of combining darcs
and git would be to use git's graph-based history model, but to
annotate the edges on the graph with semantic patches ala darcs. This
would make it possible to write smarter auto-merge strategies for git.
On Tue, Dec 7, 2010 at 7:16 AM, Stephen J. Turnbull
Ganesh Sittampalam writes:
> I think there are three things that can help with this problem: > > 1) a darcs rebase command. This will give you a nice way to manage the > workflow already discussed, and you won't have to squish everything > through into a mega-patch. You'll still have to periodically abandon one > branch for another though (but I think that's also the case with git > rebase).
I'm not sure what you mean by "abandon".
In a git rebase, you pretty much have to forget the original branch immediately (everywhere in the world!), or there will be great fun for all concerned. You really really do not want to merge an original branch with its rebased descendant in git.[1] Unfortunately, unless the rebased branch gets dibs on the branch's name, it's all too easy to perform such a merge inadvertantly (eg, git pull will do it). So in that sense a git rebase means immediately abandoning the old branch, and all the commit history of the old branch. (The details of the history are copied into the rebased commits, but they do not have the same identity as the originals, so merge conflicts are guaranteed.)
> I also have some hope, though this is more speculative, of offering > a clean way of tracking the relationship between the old branch and > the new branch so that any stray patches against the old branch can > be cleanly rebased to the new branch later on.
As explained above, DAG-based VCSes like git can't do this cleanly (that is one way of expressing the reason why rebase is severely deprecated in some circles), and I don't think git will be able to do so in the near future. OTOH, if Darcs gets rebase but can't handle this, I'd have to count that as a net minus. Recombinant patching is really what Darcs is all about IMO.
In practice, git rebase needs to be kept private to a single user, and is impractical even if private, if the user has propagated the branch to other local repositories. Because git branching is so lightweight, nobody really sees this as a big problem; throwaway branches are used all the time as interim steps in many operations (eg, git stash). Darcs branches, on the other hand, are much more heavyweight (modulo the work you propose on colocated branches, but that's farther away than rebase is).
IMHO YMMV. But I strongly recommend you think carefully about this. Analogies to git rebase are a trap here. It's implemented differently and used to solve different problems from the way rebase is proposed for use in Darcs.
Footnotes: [1] There may be better ways to deal with this than garbaging the original commits, but so far nobody really needs it.
| known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite "how to understand git" doc, do point me at it. Simon
I like Git for Computer Scientists [1] and Git in pictures [2]. It also sounds like a Git for Darcs users might be in order. Edward [1] http://eagain.net/articles/git-for-computer-scientists/ [2] http://blog.nelhage.com/2010/01/git-in-pictures/
On Wed, Dec 8, 2010 at 12:31 PM, Edward Z. Yang
I like Git for Computer Scientists [1] and Git in pictures [2]. It also sounds like a Git for Darcs users might be in order.
Once you got the general ideas down I'd recommend http://nvie.com/posts/a-successful-git-branching-model/ as a way to work with branches. Johan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/8/10 03:45 , Simon Peyton-Jones wrote:
| known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win.
I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite "how to understand git" doc, do point me at it.
I'm tempted to point out that Linux named it "git" for a reason. :) Mercurial might be a better choice, especially for people familiar with darcs. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/sgQACgkQIn7hlCsL25WV7gCdF48m1hMxoQUc/NpW08zfye3P 7+sAnRy8ef3nImblBPGcXQPCzFWbdP2h =/Xf1 -----END PGP SIGNATURE-----
On Dec 8, 2010, at 2:45 AM, Simon Peyton-Jones wrote:
If anyone has a favourite "how to understand git" doc, do point me at it.
You may have already tried these, but I've found the [official git tutorial][1] to be pretty decent. The [second part][2] contains some details on how git sees the world. The [everyday git][3] document gives a pretty good idea of how the commands are used in standard workflows. [1]: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html [2]: http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html [3]: http://www.kernel.org/pub/software/scm/git/docs/everyday.html
Hi Simon,
Simon Peyton-Jones
| known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win.
I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite "how to understand git" doc, do point me at it.
I've felt the same for quite some time. Therefore I used to prefer mercurial, because of its way more consistent user interface. But my view has changed after I've seen this [1] introduction of magit [2] an emacs git user interface. Now, I feel at least capable of working with git in emacs. [1] http://vimeo.com/2871241 [2] http://philjackson.github.com/magit/ Cheers, Jean-Marie
Hi Simon, On 12/08/2010 12:45 AM, Simon Peyton-Jones wrote:
I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite "how to understand git" doc, do point me at it.
If you still are looking for git docs (or christmas gifts, for that matter ;), I've heard good things about Pro Git: http://www.amazon.com/Pro-Git-Scott-Chacon/dp/1430218339/ref=sr_1_1?ie=UTF8&qid=1293052240&sr=8-1
Iavor Diatchki wrote:
I use git for a lot of my development... Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution.
Why do you say there is no obvious solution? In fact, Ganesh, representing the Darcs team, responded:
1) a darcs rebase command... very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it...
2) multi-branch repos... perhaps the release after next...
3) Better performance when there are conflicts... [by upgrading GHC to v2 patches]
4) Better UI around managing conflicts...
5) new patch types that reduce the number of conflicts you get at all
Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. After focusing mostly on performance for a while and achieving huge gains, the Darcs team has turned a significant portion of its attention to the branching problem for some time now, and the fruits of this labor will begin to become available in the next release. VCS discussions tend to spark religious wars in which zealous proponents of one system conveniently ignore the positive points of another in order to push as hard as possible for the adoption of their darling. Standing somewhat on the outside, it seems to me that the discussion about switching VCS has been more than thoroughly exhausted. Even when Darcs was in a far less advanced state than it is in now, the conclusion seemed to be that the best interests of the Haskell community at large are served by remaining with Darcs. So it would be a bit strange if this branching issue, which is a serious issue currently but will likely become a non-issue in a few months time, triggers GHC to abandon Darcs. On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Regards, Yitz
Yitzchak Gale wrote:
Iavor Diatchki wrote:
I use git for a lot of my development... Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution.
Why do you say there is no obvious solution? In fact, Ganesh, representing the Darcs team, responded:
Actually, I would have to agree with Iavor's characterisation here :-) I think he means that there is no obvious solution in terms of how he could change his workflow right now.
1) a darcs rebase command... very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it...
This will be technically inferior to using "normal" merging, because of the incompatible histories. *However* (as I also said) I do have some hope that darcs rebase can be made better than git rebase by actually being able to track the relationship between the old and new branches and thus allowing other branches made from the old branch to be brought up to date with the new branch. I don't think this really means "higher-order" version control as Iavor suggested - it's more a question of keeping around some information that is available at the time of doing the rebase. I think if this feature does prove possible - and I should know that within a couple of months - then darcs rebase would be quite close in usability terms to a normal git merge. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
| thoroughly exhausted. Even when Darcs was in a far | less advanced state than it is in now, the conclusion seemed | to be that the best interests of the Haskell community at | large are served by remaining with Darcs. So it would be a bit | strange if this branching issue, which is a serious issue | currently but will likely become a non-issue in a few months time, | triggers GHC to abandon Darcs. Let's not go overboard here. Iavor was expressing his frustration with using Darcs, and that is useful information for the Darcs devs to have, so they know where to focus their efforts. Already this thread has generated new useful information. For example, Iavor knows about --skip-conflicts, and I know that things might be better in months not years. Neither of us knew those things before. For GHC, we have two strong incentives to stick with Darcs. First, we use it at the moment and there'd be a lot of hoo-ha to change. Second, Darcs is written by people in our community, and GHC is a big "customer", so I for one am keen to be supportive. But we don't want to discourage people who'd like to help with GHC either. For example, here is one response to the thread, from Tim Middleton: | For the record, I can say that as a Haskell fan and someone who's using | Haskell at work (for small tools and projects), and as someone who'd like | to contribute to GHC (especially to the cross-compiler effort), having to | work with darcs is a very frustrating. The more everyone can do to understand what the frustration is, and to describe workflows that make it as easy as possible, the better. Simon
On 08/12/2010 17:39, Yitzchak Gale wrote:
Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs.
I think that might be a little overoptimistic. The fundamental problem with darcs is that nobody understands the semantics. Until there's a proper semantics that people can understand, I don't think the problems with merging and conflicts can really be fixed. Even if the semantics can be nailed down, there are some difficult UI issues to solve. We're not moving to v2 patches right now because we have enough experience with v1 to know how to avoid the bugs, but I'm less sure we could avoid the bugs in v2. To the darcs folk: do you think this is unfounded paranoia?
On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless.
Opinion on whether we should switch seems to be pretty evenly split at the moment (personally I'm agnostic). Besides that, the main stumbling block is that the GHC tree consists of about 20 repos, with different maintainers, so making it so that a GHC developer only needs to use one VC tool could be tricky. Cheers, Simon
On Thu, 9 Dec 2010, Simon Marlow wrote:
On 08/12/2010 17:39, Yitzchak Gale wrote:
Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs.
I think that might be a little overoptimistic. The fundamental problem with darcs is that nobody understands the semantics. Until there's a proper semantics that people can understand, I don't think the problems with merging and conflicts can really be fixed. Even if the semantics can be nailed down, there are some difficult UI issues to solve.
We're not moving to v2 patches right now because we have enough experience with v1 to know how to avoid the bugs, but I'm less sure we could avoid the bugs in v2. To the darcs folk: do you think this is unfounded paranoia?
Sadly, no.
On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless.
Opinion on whether we should switch seems to be pretty evenly split at the moment (personally I'm agnostic). Besides that, the main stumbling block is that the GHC tree consists of about 20 repos, with different maintainers, so making it so that a GHC developer only needs to use one VC tool could be tricky.
My feeling is that a bridge should be quite feasible and would offer those contributors who want it the opportunity to do their GHC development in git and only use darcs when submitting their final changes or when working in unbridged repos. I'm not too familiar with the structure of the GHC repo but I suspect that only a few of the subrepos are big or active enough that darcs is really painful. Cheers, Ganesh
participants (12)
-
Brandon S Allbery KF8NH -
Brian Bloniarz -
David Peixotto -
Edward Z. Yang -
Ganesh Sittampalam -
Iavor Diatchki -
Jean-Marie Gaillourdet -
Johan Tibell -
Simon Marlow -
Simon Peyton-Jones -
Sittampalam, Ganesh -
Yitzchak Gale