[darcs-users] rebase: initial preview release

[Sittampalam, Ganesh]

Simon Marlow wrote:
> On 17/08/2010 22:27, Ganesh Sittampalam wrote:

>> Please do send as much feedback as you can. There's lots I know I
>> need to do, but also a lot of uncertainty around how the UI should
>> behave. 
> 
> I just tried this out, using a local branch of GHC with a sequence of
> 9 fairly large local patches, which was a couple of months behind the
> main trunk.  I had about 500 patches to pull, of which a sequence of
> 12 were in conflict with my local changes.   
> 
> Overall, it went very smoothly - I completed the merge in less than
> an hour, and all the conflicts I was presented with looked
> reasonable. 'darcs check' after the merge succeeded.  So this is
> great! There's no way I could have completed this merge without
> rebase. 

Excellent, and thanks for all the feedback below.

> However, the workflow has some unnecessary steps

One important unnecessary step I'm already in the progress of removing
is the need for an explicit 'rebase start' and 'rebase finish'. Right
now my implementation of that eats the entirety of the repository, so a
bit more tweaking is required ;-)

> I have 'pull --skip-conflicts' in my ~/.darcs/defaults, and this
> seems to apply to 'darcs rebase pull' too, which it probably
> shouldn't (I'd like to specify defaults for rebase pull separately).  

I implemented 'rebase pull' with some cut and paste, so it probably does
so by accident :-)

However at the moment I'm not sure whether rebase pull and pull should
be separate commands or not (and at some point in the future I will
probably add 'rebase amend-record' and the same question will arise). On
the one hand they have a lot of commonality. On the other hand it might
be best for all the rebase-related commands to live in one place so that
you can't jump into relatively advanced functionality by accident.

I guess being able to specify separate defaults is a good argument for
keeping them separate.

> This one would have helped me most: as far as I can tell 'rebase
> unsuspend' doesn't understand --skip-conflicts: it would be really
> useful if it did, so that I could amend-record the conflicting patch
> and then unsuspend all the remaining non-conflicting patches.

Right, that makes a lot of sense. I'll get to that as soon as I can.

> I
> suppose what I really want is '--one-conflict', which would unsuspend
> all the non-conflicting patches and at most one conflicting patch (I
> like to deal with conflicts one at a time, my brain can't cope with
> any more).       

Yeah, I remember we discussed this workflow. With --skip-conflicts and
--all (which may not exist yet either), you could simulate it with two
invocations. That's perhaps not ideal, but may be good enough and
obviously there's a trade-off in terms of general UI complexity.
 
> The conflict markers are substantially less than helpful, but we knew
> this already.  What would make it much easier is to have a simple way
> to show the 3 versions (or original + 2 diffs) in each conflict,
> clearly annotated with which is which.   

Right, yes. This is clearly something darcs would benefit a lot from in
general.

One slight complication with rebase is that we actually throw the
conflict away after marking it in the working directory, by doing the
equivalent of an amend-record with no changes on the unsuspended patch.
With normal conflicts the conflict details can be recovered from the
repo state just by looking at the patches again - but 'darcs
markconflicts' won't work after a rebase conflict. So any new command
that made it easier to inspect existing conflicts might not work
properly in this context.

The technical reason for this is that if I left the conflict patch in
the natural representation, it wouldn't necessarily correspond to any
actual patch further back in the history, and that could lead to
problems further down the line if the conflict isn't amended out. I
think we need a better half-way house between the two options, for
example by keeping the recently unsuspended patch in a special state
that does store the conflict, but forcing the user to amend it out
before finishing the rebase.

> The message "The following local patches are in conflict:" is printed
> even if there are no local patches in conflict. 

Noted.

> What happens if you don't say 'y' to suspend all the patches that you
> are presented with, during 'darcs rebase pull'?  Would it be possible
> to recover from doing that by accident?  

Assuming you've got beyond the point where you can just ^C, you can
unpull all the patches that were pulled in and the redo the 'rebase
pull', and it'll offer any unsuspended patches again. Not exactly
friendly, though. If you can remember what they were, you could also
manually suspend the patches that you previously said 'n' to with
'rebase suspend'. Any ideas on a nicer workflow?
 
> The patches to suspend seem to be presented in reverse order: if I
> unsuspend I get them in the other order. 

The suspended patches are LIFO. When selecting patches to suspend, it's
like selecting patches to unpull; if '6' depends on '4', you have to
agree to suspend '6' before you can suspend '4'. When unsuspending, it's
like pull because you need '4' before you can have '6':

normal patches -> 123456 abcde <- suspended patches
                        ^
                        this is where pristine is. Suspension
                        and unsuspension involves commuting if
                        necessary then (roughly) moving the
                        pointer.

Obviously this didn't match with your initial expectations/intuition,
but do you think it's confusing enough that I should try to change it? 

> 'rebase pull' is a bit slow: about 15s to completion after asking
> which patches to suspend. 

Is that any slower than it would have been if you'd instead unpulled the
patches that needed to be suspended and done a normal pull? Suspending
patches does involve some work but especially now the 'NewSet' changes
are in so darcs doesn't rewrite the entire history of inventories on
each update, it shouldn't be that slow.

One situation I'm somewhat concerned about is the situation where a lot
of patches are suspended. I don't know how common this is likely to be -
but they are stored in a single patch file so it won't scale well.

Ganesh

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
===============================================================================