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

[Florent Becker]

trentbuck at gmail.com (Trent W. Buck) writes:

> Florent Becker <florent.becker at ens-lyon.org> writes:
>
>> 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.
>
Yes, that's a good idea.

>> 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"?
>
Not necessarily, I was proposing to add this question to all interactive
patch selections. 's' would arguably be more useful with record than
send. Still, I can see some use for it with send. For example, if you
spot a mistake you've made in one of your patches when you prepare for
sending, you might want to feed the selection of patches you've made to
unrecord.

>> 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.

The problem with --dry-run is that you have to know that you are going
to need it before you run the command, which is not always the case for
mere mortals. What's more, --dry-run (or the 's' proposal above) should
really be compatible with --interactive, and output (at least
optionnaly) in a format that can be read back by darcs. When
dependencies grow hairy, consistent patch selection is work, and it has
to be saveable somehow. I'm afraid that if we go with --dry-run, then
the recommanded workflow will be to first select with --dry-run
--interactive, then do the real thing with --read-from-file, and it is
not user-friendly at all.

Florent.