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.