[PATCH stable] rebase: add return codes

Jason Harris jason at jasonfharris.com
Thu May 20 16:03:04 CDT 2010


On May 20, 2010, at 5:05 PM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
>> On May 20, 2010, at 3:41 PM, Martin Geisler wrote:
>> 
>>> If there is nothing to do, then I think that should count as a
>>> succesful rebase.
>> 
>> Well... Right now "pull" with nothing to pull returns exit code 1,
>> which to me still feels wrong but Matt says it makes it easy to code.
>> (I personally don't think this a good reason to issue that exit code.)
>> 
>> In that email thread I started titled "Versioning of external
>> extensions?"... Matt Mackall said:
>>> For the most part, things work like this:
>>> 
>>> 0: success
>>> 1: nothing to do, unresolved files, no matches, non-fatal errors
>>> 255: abort or other exception
> 
> Oh, right, I remember that now. That strategy allows one to use '&&' on
> the command line to mean 'continue if succesful and something happened'.
> Very reasonable.
> 
>> [...] I just don't think a pull with nothing to pull should be an
>> abnormal error, or indeed a rebase with nothing to do should do an
>> "abnormal termination".
> 
> Yeah, calling it "abnormal termination" makes it sound worse than it is.

"abnormal termination" are the words from the python documentation, not mine :)

> The good old grep(1) has exit code 0 for "lines found", and 1 for "no
> lines found", and 2 for error. The grep(1) man page says that posix
> mandates an exit code great than 1 in case of error.

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

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...

Still at least I have some description now so I shouldn't complain to loudly :)

Cheers,
  Jas


> -- 
> Martin Geisler
> 
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/mercurial/



More information about the Mercurial-devel mailing list