[darcs-users] rebase: initial preview release

[Ganesh Sittampalam]

On Mon, 23 Aug 2010, Simon Marlow wrote:

> On 20/08/2010 13:40, Sittampalam, Ganesh wrote:
>> Simon Marlow wrote:

> I'd be quite happy with a UI that did something like:
>
> $ darcs pull
> ...
> There are N patches to pull that conflict with M patches in your repository.
> [P]ull anyway, and resolve conflicts later
> [S]uspend the local conflicting patches, and rebase later
> S[k]ip the conflicting patches, just pull the others
> S[h]ow me the patches that are in conflict
> [Q]uit, pulling no patches at all
> ?
>
> and the chatty UI would be disabled if you give an explicit option such as 
> --skip-conflicts or --allow-conflicts.

OK, thanks. I need to keep thinking about this one, I think, and there's a 
general redesign of the conflict acceptance UI implied here too.

>>> 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?
>
> I suppose my question is more along the lines of "what state does it leave 
> your repository in, how can you tell what has happened, and how do you 
> recover?".

OK. This is connected to better information around conflicts, I guess - 
i.e. being able to tell what is actually in conflict.

>>> '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?
>
> pulling a few patches takes less than 2 seconds, unpulling takes about 3-4 
> seconds with 2.4.98.  This is on NFS.  It's certainly faster with 2.4.98 than 
> it used to be with 2.4.4, but not the 0.1s I was hoping for.  The 15s to 
> suspend patches does seem a lot slower than I expected, but then these were 
> quite large patches I suppose.

OK, so clearly room for improvement, but it's probably explained by 
needing to build and write the suspended patch. Is that sort of order of 
magnitude performance ok, or should I make improving it a priority?

Ganesh