[PATCH 2 of 3] update: allow branch crossing when clean
Stuart W. Marks
smarks at smarks.org
Thu Sep 17 12:27:25 CDT 2009
Hi guys,
Thanks for picking up this thread. I've been meaning to resubmit the patches,
and this gives me a bit of impetus to do so. I'll try to do this later today.
Further discussion below.
Adrian Buehlmann wrote:
> On 17.09.2009 14:33, Martin Geisler wrote:
>> Adrian Buehlmann <adrian at cadifra.com> writes:
>>
>>>>> + if check and clean:
>>>>> + raise util.Abort(_("can't specify both -C and -c"))
>>>>> +
>>>> No, I think we should keep to full, proper English sentences. I'll
>>>> have to write 'kan ikke' (cannot) in Danish anyway since we don't
>>>> have a word for the contraction. I also prefer the full option names
>>>> since I think they add clarity.
>>> Well, I thought if it is good enough for tar we could do something
>>> similar
>>>
>>> %tar xc
>>> tar: Can't specify both -c and -x
>> It was just my opinion, I did not look at other program to compare.
>
> Well. I don't insist here. If it helps increasing chances that we
> get *any* warning for -Cc into the code base, I'm all for using the original
> proposed part of the patch (I almost regret having proposed a variant,
> I was thinking I could actually increase chances getting that change in :)
The original message from the patch was "cannot specify both --check and
--clean at the same time" which, now that I look at it again, is redundant.
It's unnecessary to say "both" and "at the same time". This can certainly be
shortened to
"cannot specify both --check and --clean"
The source base seems quite inconsistent on its use of short or long options in
error messages. But it seems like you guys had agreed that there are already
more mentions of '-C' than '--clean' so I can certainly go with this:
"cannot specify both -c and -C"
It's probably also worth breaking this into a smaller, self-contained patch as
you suggested. I'll do this when I resubmit unless Martin or somebody beats me
to it.
> One last point though is: I have learned (the hard way) that
> -C is damn dangerous. So I like that I have to reach for the
> shift key for using it.
I agree! The overloading of -C to mean "discard changes" and "allow crossing to
another branch [on the same named branch]" has always bothered me, precisely
because it's so dangerous.
>> I also thinks is a shame we have a message suggesting 'hg up --clean'
>> instead of 'hg update --clean'. I think we should refer to the commands
>> by their full names.
>
> I fully agree with that. Using 'hg up' in messages should be avoided.
>
>>> Are you going to change these too?
>> No, it would break scripts that look for the short form.
Are error messages really considered part of the interface for compatibility
purposes? I note that http://mercurial.selenic.com/wiki/CompatibilityRules says
"Changes to error messages and ui.debug messages are usually fine as most of
these messages are not intended for parsing." Well, I'll submit a separate
patch to fix this, and if it's deemed to be incompatible it can simply be rejected.
s'marks
More information about the Mercurial-devel
mailing list