[Haskell-cafe] Re: [ANNOUNCE] git-darcs-import 0.1

[Aaron Denney]

This is drifting off-topic, but...
On 2008-06-03, Peter Hercek <phercek at gmail.com> wrote:
> Aaron Denney wrote:
>> On 2008-06-03, Peter Hercek <phercek at gmail.com> wrote:
>>> Loup Vaillant wrote:
>>>> 2008/6/3 Darrin Thompson <darrinth at gmail.com>:
>>>>> <--cut-->
>>>>> What's the appeal of this? I personally love git, but I thought all
>>>>> the cool kids at this school used darcs and that was that.
>>>> Disclaimer: I'm no expert, this is what I've heard. Anyone please
>>>> confirm or deny the following?
>>>>
>>>> Basically, git is waaay faster than Darcs on a number of use cases.
>>> Other reason can be "git rebase". Of course there is a question
>>>   how good practice it is ... but it is being used.
>> 
>> Darcs patches are pretty much an implicit rebase.
>
> You cannot push patch B if it depends on patch A without also
>   pushing A. And darcs currently does not alow you to reorder
>   B before A

True.  This is a *feature* not a bug.  You shouldn't be able to do this
automatically, because it can't be done right.  You need to do this sort
of thing manually.  If you don't, the heuristics used will bite you at
some point.  When they do commute, there is no problem.

> Git rebase works quite well even in cloned repositories.

Meh.  It can, if you're really really lucky.

> See: http://bugs.darcs.net/issue891
> Some discussin about it is also here:
> http://lists.osuosl.org/pipermail/darcs-users/2008-February/011564.html
>
> When the issue is fixed then darcs will be really patch based and
>   will become the ultimate DSCM :-)

Rebasing is doable in git as a one-repository operation because each
repository has multiple branches.  As darcs has one repo per branch,
it fundamentally needs to be done in multiple repos.

There are naturally two repos, upstream, and your-feature-development.

your-feature-development has a patch A that you want to rebase.

What you should do is pull upstream into new-tracking, then pull patch A
from your-feature-development into new-tracking.

If it applies with no problem, great: mv your-feature-development
your-feature-development-old; new-tracking your-feature-development.
Of course, in this case, you could have just pulled into
your-feature-development.  If there weren't any other patches to save in
the old your-feature-development, you can delete it instead of moving
it.

When there is a conflict, then you need to handle it somehow.  Neither
git nor darcs can do it automatically.  You can just record the merge
conflict and your resolution.  This keeps repos that pulled from you
valid, but this won't give you the "clean history" that you presumably
want.  So you need to combine the merger and cleanup into a new patch
with the same log message, etc.  It's true that git does make *this*
process very nice.

There is one thing that git rebase does easily (and correctly) that darcs
doesn't do nicely: rewriting history by merging commits "prior" to the
head.  I put prior in quotes, because darcs doesn't preserve history
in the first place.  I don't find that a compelling use, as opposed to
maintaing topic branches.

-- 
Aaron Denney
-><-