[PATCH stable] rebase: add return codes

[Jason Harris]

On May 21, 2010, at 10:17 AM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
>> I think the grep code might be a bit more exceptional in this regard.
>> Moreover Mercurial is a *vastly* *vastly* more complicated program
>> than grep. Thus since grep returns 0 or 1, it doesn't simply follow
>> that Mercurial should follow this. Just returning 0, 1, or 255, when
>> GUI clients are meant to connect to this and "do the right thing" is
>> well not quite detailed enough on Mercurial's part.
>> 
>> If you look at for instance:
>> http://www.freebsd.org/cgi/man.cgi?query=sysexits&sektion=3
> 
> Yeah, I know about those exit codes and they are even part of the os
> module in Python (at least on Unix).
> 
>> You will see a lot of detailed codes. It would be nice if the
>> Mercurial exit codes where broken down a little more into something
>> like:
>> 
>> 0: success
>> 2: empty result
>> 3: no action taken
>> 4: unresolved files
>> 5: uncommitted changes
>> 6: unreachable server
>> ...
>> 
>> I am sure you devs can come up with a nice group...
> 
> Don't you think you would still need code to parse the output in order
> to give proper error messages to the user?

Well there are a few cases one needs to do, but a lot of the critical errors are pretty easy you just make sure the history and or file statuses are up to date after the command and post a dialog with the text of stderr of the task.

Its the warnings which are tricky. Because you have things like pulling when there is nothing to pull looks like its is sending a pretty serious error, so I need to put work arounds in my code to handle that. Sometimes the warning is on stderr, and sometimes on stdout, etc. And as the policy is pretty loose and general in terms of what errors / warnings are given when and how, then basically I have just coded things generally, and as I / users stumble across some error which isn't handled well I will put something in my code. But trying to do a full on parse and capture every type of error means my code would have to track every command and their possible error codes. I would have to scan the internals of the Mercurial code at each release... which is just not going to work. It would be much better for Mercurial to give more fine grained errors.

But thanks for the question! :)

Cheers,
  Jas

>> Still at least I have some description now so I shouldn't complain too
>> loudly :)
> 
> 
> 
> -- 
> Martin Geisler
> 
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/mercurial/