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 <step...@xemacs.org> wrote: > 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. > > _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
