[PATCH 4 of 4] mq: introduce mq.check setting

[Angel Ezquerra]

On May 12, 2012 6:11 PM, "Patrick Mézard" <patrick at mezard.eu> wrote:
>
> Le 12/05/12 17:56, Angel Ezquerra a écrit :
> > On Sat, May 12, 2012 at 5:02 PM, Idan Kamara <idankk86 at gmail.com> wrote:
> >> On Sat, May 12, 2012 at 5:55 PM, Angel Ezquerra <
angel.ezquerra at gmail.com>
> >> wrote:
> >>>
> >>>
> >>> On May 12, 2012 4:49 PM, "Patrick Mézard" <pmezard at gmail.com> wrote:
> >>>>
> >>>> Le 12/05/12 16:13, Patrick Mézard a écrit :
> >>>>> Le 12/05/12 15:00, Angel Ezquerra a écrit :
> >>>>>> On Sat, May 12, 2012 at 11:00 AM, Patrick Mézard <patrick at mezard.eu
>
> >>>>>> wrote:
> >>>>>>> Le 12/05/12 10:37, Angel Ezquerra a écrit :
> >>>>>>>> On May 12, 2012 10:09 AM, "Matt Mackall" <mpm at selenic.com> wrote:
> >>>>>>>>>
> >>>>>>>>> On Sat, 2012-05-12 at 01:12 +0200, Patrick Mezard wrote:
> >>>>>>>>>> # HG changeset patch
> >>>>>>>>>> # User Patrick Mezard <patrick at mezard.eu>
> >>>>>>>>>> # Date 1336774770 -7200
> >>>>>>>>>> # Node ID ed81cb27341e285d539617ba961f48c69dd18135
> >>>>>>>>>> # Parent  f4da2aeb000408aa54f59829acb092ec85914475
> >>>>>>>>>> mq: introduce mq.check setting
> >>>>>>>>>
> >>>>>>>>> Nice, these are queued for default.
> >>>>>>>>
> >>>>>>>> Patrick,
> >>>>>>>>
> >>>>>>>> I'm curious, why did you choose "check" as the name for this
> >>>>>>>> option? It
> >>>>>>>> does not seem obvious to me...
> >>>>>>>
> >>>>>>> I have not given much thought to it. --check makes it sound like
> >>>>>>> qpush/qpop will closely "check" the local changes before deciding
to bail
> >>>>>>> out or not. The setting is named after the command line option.
Maybe this
> >>>>>>> is a mistake, if you have something better to suggest, feel free
to submit a
> >>>>>>> patch, that is exactly the right time to change it.
> >>>>>>
> >>>>>> There is a --check (-c) option for update. Its definition is"
> >>>>>>
> >>>>>> -c --check     update across branches if no uncommitted changes
> >>>>>>
> >>>>>> It does not sound anything like this option (IMHO). In fact, it
seems
> >>>>>> as if where quite the oposite. On the hg help update text it says:
> >>>>>>
> >>>>>> "    2. With the -c/--check option, the update is aborted and the
> >>>>>> uncommitted
> >>>>>>        changes are preserved."
> >>>>>>
> >>>>>> That is, with the -c option, the update will be aborted if there
are
> >>>>>> uncommitted changes, which is in fact the opposite of what this
does,
> >>>>>> isn't it?
> >>>>>
> >>>>> You may be right.
> >>>>>
> >>>>>> what about --nocheck (-n)? After all this does the opposite thing
of
> >>>>>> what --check does for update (if I undestand things correctly).
> >>>>>
> >>>>> [-n] is used for --dry-run so not this short option. Obviously, it
is
> >>>>> difficult for me to consider --no-check, since the code actually
checks more
> >>>>> things than the regular version (but is more lenient in its
findings). Also,
> >>>>> --no-check feels a bit like "I am not checking anything, all bets
are off, I
> >>>>> hope you had backups". But maybe.
> >>>>>
> >>>>> What other people think?
> >>>>
> >>>> Idan: --disjoint
> >>>> Me: --keep-changes or --keep
> >>>>
> >>>> --
> >>>> Patrick Mézard
> >>>>
> >>>
> >>> I like --keep. I don't really understand --disjoint.
> >>
> >> It describes more accurately what's happening: allow
> >> qpush if patched files and dirty files in wd are disjoint.
> >>
> >> But --keep might be simpler and more familiar.
> >
> > I see. That makes sense, but as you say --keep is probably easier to
> > understand even if it is not as accurate.
> >
> > Do you guys want me to send a patch or will you change it?
>
> I will wait a bit then rename to keep if nobody else complains.
>

Patrick,

as you said, the main issue with making this the default behavior is that
people could qrefresh and inadvertently add their modified files to the
refreshed patch. That made me think, wouldn't it be nice to also add an
option to qrefresh to only update the files that are already on the patch?
But it turns out that there is already such an option, -s or --short!

The actual option name is not as clear as it could be, but still, I love
how the mercurial UI is so well thought! :-)

Cheers,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120513/646ab8c6/attachment.html>