[darcs-users] darcs patch: refactor of SelectChanges (and 1 more)

Trent W. Buck trentbuck at gmail.com
Mon Oct 13 03:17:42 UTC 2008


Florent Becker <florent.becker at ens-lyon.org> writes:

>>     Pull C?  y
>>     That patch has dependencies that you haven't pulled!
>>     Pull them, too? ask
>>     Pull A? y
>>     Pull B? y
>>     Done asking about dependencies.
>>     (Here it would ask about other matching patches, e.g. C1).
>>     Done. (No change.)
>>
>> In my mockup, the new --dont-prompt-for-deps corresponds to a "yes to
>> all" response to the "Pull them, too?" question.
>
> The problem I see is that SelectChanges' code really wants to ask only
> once about each patch, and to ask about them in dependency order. I'm
> also not sure what we can do within the limitations of the sequential
> prompt/answer paradigm.

Then I'm gonna take a hard line and say that (long term) the code ought
to be rewritten to support an interaction like that mockup.

(This is not to detract from the work you've already done; it's an
improvement over the previous functionality.  But there's still room for
big improvements to the usability of this workflow.)

>  1/ add a 'last-exit' question, as proposed elsethread, so that
> --dont-prompt-for-deps does not act that silently. In a
> second time, add your 'that patch has dependencies, pull them?'
> question, albeit in "an all or nothing" fashion. We could simply add a
> warning "this patch has unpulled dependencies", show them when the user
> hits 'v' (in addition to the patch), and offer him to either pull the
> patch with all dependencies (with 'y'), or not (with 'w/n'). This is
> what i see how to implement in the current state of darcs.
>
>  2/ Work on making SelectChanges code callable from outside darcs, as a
> lib, or as specialised darcs commands/flags (ie either
> Darcs.SelectChanges.getDependenciesForSelection, or darcs pull --dry-run
> --dont-prompt-for-deps --read-selection FILE) so that we can code a more
> featureful (maybe graphical) UI outside of darcs. There we could get rid
> of the sequential prompt/answer paradigm, and have richer interactions.

I agree with the idea of a libdarcs that other apps can talk to.  But I
still think my mockup workflow deserves to be in Darcs proper, rather
than relegated to a separate opt-in application.



More information about the darcs-users mailing list