[PATCH 2 of 3] patchbomb: customize promptchoice to allow localization of choices

Gilles Moris gilles.moris at free.fr
Tue Aug 31 02:14:08 CDT 2010


On Monday 30 August 2010 03:37:50 pm Christian Ebert wrote:
> * Mads Kiilerich on Monday, August 30, 2010 at 14:39:55 +0200
>
> > On 08/28/2010 11:44 AM, Christian Ebert wrote:
> >> * Christian Ebert on Saturday, August 28, 2010 at 01:03:42 +0100
> >>
> >>> * Mads Kiilerich on Saturday, August 28, 2010 at 00:01:37 +0200
> >>>
> >>>> --diffstat apparently does something quite similar to what you
> >>>> introduce with --confirm.
> >>>
> >>> It asks for confirmation of the diffstat of each patch. 3 patches
> >>> ->  3 prompts. confirm: 3 patches: 1 prompt. And, well, diffstat
> >>> shows the diffstat, and confirm shows the message details,
> >>> sender, recipients, subjects.
> >>>
> >>>> What is your thoughts regarding that? Are both of them needed and do
> >>>> they supplement each other? Could --diffstat be expanded instead of
> >>>> introducing a new option - or should --diffstat be deprecated?
> >>>
> >>> Frankly, I don't understand you there. Sorry.
> >>
> >> In my eyes there's a fundamental difference between diffstat and
> >> confirm, as diffstat changes the messages themselves. That's why
> >> the 2 options only overlap by presenting a boolean prompt (and
> >> diffstat does this for each patch as well for the whole series)
> >> and not in their, errmh, content ... But I probably still don't
> >> understand your question.
> >
> > I doubt there is an answer, so it probably wasn't a question at all ...
> >
> > I just wanted to raise some attention to the fact that we now are
> > introducing a second completely different option for patchbomb
> > confirmation.
>
> I know, I think patchbomb is quite cluttered with, errmh,
> features already, which is why in February I introduced --confirm
> via the backdoor by simply abusing --verbose. After all a
> confirmation is verbose ;-) But I agree that this would be very
> unclean and "surprising".
>
> > It is unfortunate that --diffstat does two completely different
> > things. Couldn't that be considered a ui bug that should be fixed?
> > ;-)
>
> I'm not using diffstat, but the diffstat confirmation does a
> different thing than the confirm option: it asks to check the
> _contents_ of each email, whereas --confirm asks to check sender,
> recipients, and subjects. So from my pov 2 options actually make
> sense.
>
> > It could be nice if the two kind of prompts could be unified
> > somehow. That is however probably hard to do while preserving
> > backward compatibility. The fact that it is an interactive command
> > makes scripting less of an issue, but still there might be some
> > users that are used to rely on the prompts and would get an
> > unpleasant surprise if it was changed ...
>
> One could consider to merge at least the final diffstat for the
> whole series into the --confirm prompt. otoh this would muddle
> up the purposes of the 2 boolean prompts again.
>
> > IMHO, ideally --diffstat should _only_ cause diffstat to be put in
> > the mails. It would be fine with me if --confirm always showed
> > diffstat together with each subject and was the only way to get a
> > confirmation prompt.
>
> Perhaps users of --diffstat should chime in. Was implementing the
> prompt after each mail in the series intentional?
>
> For the moment however, I'd prefer --confirm to be treated
> separately, and not mixed up either with --diffstat or the
> handling of Cc prompts, like it happened in February. Otherwise
> this just left hanging in the air again. Which is a long version
> of saying: I think the 2 remaining patches should go in -- *if*
> we want the confirm feature.
>
> c

It would indeed be great to have --diffstat and --confirm have separate 
actions:
- diffstat to just prepend diffstat in the mail's bodies, not doing any kind 
of confirmation
- confirm to have diffstat printed just on stdout along with sender, 
recipients, subject, with just one acknowledgment for all the printed 
diffstats. Confirming each patch for long series is such painful.

For instance, I like to double check the patches diffstat before sending, but 
I know mpm is not fond of them. That's the reason I stopped using them.

Regards.
Gilles.


More information about the Mercurial-devel mailing list