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

[Aaron Denney]

On 2008-06-04, Peter Hercek <phercek at gmail.com> 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:
>      o---o---o---o---o  master
>           \
>            o---o---o---o---o  next
>                             \
>                              o---o---o  topic
> to:
>
>      o---o---o---o---o  master
>          |            \
>          |             o'--o'--o'  topic
>           \
>            o---o---o---o---o  next

apfelmus answered this.  I might expand on his reply.

>> 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.
>
> I do not know what you mean here. Can you point me to some example?

Letting capitals be commits, and lowercase be trees at the point of
these commits.

Suppose your history is:

A -> B -> C -> D
|    |    |    |
a    b    c    d

And that B somehow doesn't make sense except with the additional changes
in C.  You don't want to deal with this, or have anyone see B.  All it
does is clutter up the history.  So you want to expunged it from the
history.

git rebase can rewrite this to

A ------> C' -> D'
|         |     |
a         c     d

Doing this in darcs would require unrecording B and C, and then
rerecording C'.  But, if D is in the repo, then it is likely that B and
C can't be commuted past it to be unrecorded.  (If they can, no
problem!)

Unrecording D (and possible E, F, G, etc.) lets you do this, but if you
then pull it back from another repo, it will depend on B and C, and pull
these in, which are now doppelgangers of C'.  Not having used darcs 2,
I'm not sure if that's still quite so fatal, but it remains bad news
AIUI.

The bottom line is that darcs is a tool for managing sets of always
existing patches. and ordering them lazily, as needed.  In particular,
no history generally exists, unless each patch depends on exactly one
previous.  It has a "differential" view of software development, in that
the changes, and not the sum at each point matter (though of course, the
current sum does matter.)

On the other hand, git is a tool for managing (and munging) histories
of development in many weird and wacky ways.  It has an "integral"
view of software development, the changes are lazily derived from the
saved state at each point, and are strictly ordered even when they're
independent.  It can, when needed, work with these changes to accomplish
fairly interesting history-altering tasks, but as soon as they're used
to construct a new history, they're discarded.  (Yes, git uses deltas,
but this is "merely" an optimization.)

The two models are dual to each other in many ways.

-- 
Aaron Denney
-><-