On 2008-06-04, apfelmus <[EMAIL PROTECTED]> 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
-><-
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
