[PATCH] rebase: abort message should appear even with --quiet

[Steve Borho]

On Tue, Oct 26, 2010 at 4:37 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Wed, 2010-10-27 at 00:12 +0900, Nicolas Dumazet wrote:
>> 2010/10/27 Steve Borho <steve at borho.org>:
>> > On Tue, Oct 26, 2010 at 6:49 AM, timeless <timeless at gmail.com> wrote:
>> >> # HG changeset patch
>> >> # User timeless <timeless at gmail.com>
>> >> # Date 1288093318 -10800
>> >> # Node ID 0009d6d29ab4bc7706d8417b31fce4f57bd01c4b
>> >> # Parent  850617e3a5cc060e19d03ef5601985f6920823c9
>> >> rebase: abort message should appear even with --quiet
>> >
>> > (apologies for pseudo-hijacking this thread)
>> >
>> > A similar problem is that rebase reacts badly to unresolved merges.
>> > It raises a util.Abort() exception rather than your typical ui.warn()
>> > and exit with non-0 return code.  I think it should behave very
>> > similar to the merge command when it sees unresolved files.
>> >
>> > Current behavior:
>> >
>> > abort: fix unresolved conflicts with hg resolve then run hg rebase --continue
>> > [0]
>> >
>> > Preferred behavior:
>> >
>> > fix %d unresolved conflicts with hg resolve then run hg rebase --continue
>> > [1]
>>
>> And similarly, why does rebase return with 0 with the rebase aborts?
>> Do we want this?
>
> It definitely shouldn't. Aborts usually give a 255 error code (which is
> nicely distinct from "nothing to do"). And that's what I'm seeing in the
> test suite:
>
>  abort: fix unresolved conflicts with hg resolve then run hg rebase
> --continue
>  [255]

Oops, the zero return code is coming from my threaded
dispatch._dispatch() exception handler.  Ignore that complaint.

-- 
Steve Borho