[darcs-users] How to develop on a (GHC) branch with darcs

[Ganesh Sittampalam]

On Wed, 8 Dec 2010, Stephen J. Turnbull 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".

I mean the same as in the git world. The rebased patches have new 
identities, and if my ideas for tracking the relationship don't work out, 
they will have no relationship to the old patches.

[your very clear explanation of that snipped]

> > 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.

darcs rebase is essentially about giving up on the recombinant patching 
because that's not working out for whatever reason. It's primarily 
intended as an alternative to manually reapplying patches to new branches 
using diff-and-patch, which is something significant numbers of people 
have ended up having to do. People generally want/need to do this to avoid 
conflicts, because:

(a) darcs conflict handling can blow up, both because of exponential 
merges (primarily with v1 patches) and because of bugs

(b) the UI for dealing with conflicts isn't really that pleasant and in 
particular once you've resolved a conflict it's a little painful to see 
the overall effect of the conflict resolution together with the underlying 
patch

> 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.

My understanding is that one of the main uses for git rebase is for 
"cleaning up history" prior to submission. In that regard I think there's 
a substantial overlap with what darcs rebase is intended for.

Thanks for the detailed comments.

Ganesh