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

[Iavor Diatchki]

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