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

[Peter Hercek]

Aaron Denney wrote:
> This is drifting off-topic, but...
> On 2008-06-03, Peter Hercek <phercek at gmail.com> wrote:
>> Aaron Denney wrote:
<--- cut --->
>>> 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.

Sorry, I did not intend to indicate it should be done without doing the
  reordering first (by providing manual conflict resolution).

>> Git rebase works quite well even in cloned repositories.
> 
> Meh.  It can, if you're really really lucky.

Actually you are probably right, I needed to use a non-complicated
  workaround once (but I did it only about two times!). I might have
  been just lucky. I liked though that it did tell me what was wrong,
  in contrast to mercurial queues which just replicated both original
  branch and the rebased branch (so I finished with two copies on
  both sides at the end :-( ).

<--- cut --->

> 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.

Ok, in such a simple case darcs can preserve the message too if the
  repository is not cloned (and you indicated that it does not really
  work with cloned repositories in git - I'm not an experienced git user).
  Just pull to the original repository and use amend-record to resolve
  the conflict and the message will be preserved. So I would tell that
  for *this* *simple* case darcs is better.

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

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 do not know how to do this in darcs (without doing manual addition
  of "topic" changes with gnu patch utility in a new darcs repository
  clone which would not have "topic" changes (and "next" changes as
  well) pulled in and throwing avay the old one at the end).

> 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?

I hope that this is not too off-topic for haskell cafe ... and so far
  I believe this is not a flame war :-) I just like that Bertram's code
  exists and I think it (as well as git) should not be dismissed, since
  AFAIK there is more than performance to git as well as there is more
  to darcs than it not imposing patch order on us (which is the darcs
  feature I like).

Peter.