[darcs-users] Adding a 'last regrets' question after patch selection

Trent W. Buck trentbuck at gmail.com
Sun Oct 12 03:12:36 UTC 2008


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

> Hi all,
>
> our patch selection mechanism is very fine, but I feel it should give a
> 'last exit before hell question' at the end, so that you can review your
> patch selection before commiting to whatever action it is you're
> doing. Let me explain: suppose you are sending to a repository. You have
> three new patches: a b c, with c depending on b. You will have the
> following interaction with darcs:
>
>  'do you want to send a?' -> y
>  'do you want to send b?' -> n
>  'congratulations, you've sent a alone.' -> wtf?

I don't know if it helps, but essentially that is what I get with "darcs
send --edit", which I have enabled in my ~/.darcs/defaults.

After asking about patches, darcs starts up $VISUAL on a file that
contains the patch descriptions of outgoing patches.

> That's why i propose to add a question after the last patch has been
> selected, as follows:
>
> do you want to <verb> these <things>? [ynvpsrm]
>
> With
> y: yes, go on
> n: no, cancel
> v: view
> p: view in a pager
> s: write the output of v to a file and quit
> r: restart the selection process
> m: modify the selection
>
> m is hard to implement, but as a first approximation, we could just go
> back to the last patch question and let the user use j/k.

I'd just have "k: back" then, rather than using a different letter.

> s would be very powerful coupled with a --read-selection-from-file
> flag. You could then save your selection to a file and edit it to
> fine-tune it. In particular, in record, this would allow you to split
> hunks.

I'm confused; are we still talking about "darcs send"?

> Commands could add more specialized answers to that question: for
> example, send could propose to edit the mail, or cc: someone, and so on.
>
> Of course the problem is that this would change darcs' interactive ui
> and break any scripts that interact with it (in particular our shell
> tests). We could also add a --cautious/--reckless flag pair, but i'm not
> too keen on adding many flags, especially when --reckless would probably
> not be that useful out of existing scripts (you save one 'y', if it
> counts for you, you're not using the interactive ui, are you?). What do
> you think? Change the ui, add a flag, do nothing, something else?

Perhaps what's really desired is a --dry-run switch for all commands,
which prints a high-level description of the action that WOULD be taken,
but doesn't actually take it.



More information about the darcs-users mailing list