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

[Aaron Denney]

On 2008-06-04, apfelmus <apfelmus at quantentunnel.de> wrote:
> Peter Hercek wrote:
>> But what about this git rebasing option? How to do it more easily
>>  (than the solution I know and I described it later) in darcs?
>> 
>> using "git-rebase --onto master next topic" to get from:
>> to:
>>
>>     o---o---o---o---o  master
>>          \
>>           o---o---o---o---o  next
>>                            \
>>                             o---o---o  topic
>> 
>>     o---o---o---o---o  master
>>         |            \
>>         |             o'--o'--o'  topic
>>          \
>>           o---o---o---o---o  next
>> 
>> This is the reason why I mentioned reordering depending patches AB
>>  to BA (with manual conflict resolution) would be needed in darcs
>>  to support (I believe a better) alternative to git rebase.
>
> I don't understand (probably because I haven't use either dvcs).
>
> Either the changes in the  next->topic  path don't depend on the changes 
> in the  fork->next  path. Then, the patches commute and it's no problem 
> for darcs.

Right.  Then 

>>     o---o---o---o---o  master
>>          \
>>           o---o---o---o---o  next
>>                            \
>>                             o---o---o  topic

is not a good model for what darcs has.  What it has is more like

>>     o---o---o---o---o  master
>>         |\
>>         | o---o---o---o---o  next
>>         \                 |
>>          o---o---o--------+  topic

The patches in "topic" that are in "next" are indepent of the ones that
aren't in "next", so it's another (virtual) line-of-development, that
darcs can lazily construct as needed.  These lines-of-development are
similar to branches of git that have been merged, but you also have
access to the "unmerged" versions until a patch comes in that depends on
the merger.

If I commit three new features that don't interact, a darcs repo will
essentially look like:

       ---- topicA -
      /             \
history --- topicB --+--
      \             /
       ---- topicC -

Where the merger is "virtual".  Darcs will implicitly linearize this to
any of 
      
history --- topicA --- topicB --- topicC ---
history --- topicA --- topicC --- topicB ---
history --- topicB --- topicA --- topicC ---
history --- topicB --- topicC --- topicA ---
history --- topicC --- topicA --- topicB ---
history --- topicC --- topicB --- topicA ---

/as needed/. git constructs one of these, based on how you did the
commits, and gives you ways to alter it to the others.

> Or the  next->topic  path relies on features from  next  that are not 
> present in  master . But then, you're screwed anyway

Yep.

> and should merge some parts from next into master so as to advance the
> point where master and next fork.

That's one solution.  Of course, darcs doesn't have semantic dependency,
but syntactic dependency.  (You can add extra dependencies to
model semantic dependencies, but you can't take away the syntactic
dependencies.)  Another solution, if there's syntactic,
but not semantic dependencies, is to manually use patch and diff to get
90% there, and then cleanup and record.

-- 
Aaron Denney
-><-