[darcs-users] How to develop on a (GHC) branch with darcs
iavor.diatchki at gmail.com
Tue Dec 7 19:46:28 CET 2010
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.
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 <stephen at 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. 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.
>  There may be better ways to deal with this than garbaging the
> original commits, but so far nobody really needs it.
More information about the Glasgow-haskell-users