On 20/08/2010 13:40, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
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'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.
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.
implementation details :-)
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?".
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?
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.
Cheers,
Simon
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
