Re: [PATCH 1/2] config: define and document exit codes

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 18.05.2011 17:41:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> +This command will fail (with exit code ret) if:
>> +
>> +. The config file is invalid (ret=3),
>> +. can not write to the config file (ret=4),
>> +. no section or name was provided (ret=2),
>> +. the section or key is invalid (ret=1),
>> +. you try to unset an option which does not exist (ret=5),
>> +. you try to unset/set an option for which multiple lines match (ret=5),
>> +. you try to use an invalid regexp (ret=6), or
>> +. you use '--global' option without $HOME being properly set (ret=128).
> 
> I wonder if you want to sort this in the order of return codes.

Well, if I wanted to... ;)

I don't mind resorting.

>> +/* git_config_parse_key() returns these negated: */
>> +#define CONFIG_INVALID_KEY 1
>> +#define CONFIG_NO_SECTION_OR_NAME 2
>> +/* git_config_set(), git_config_set_multivar() return the above or these: */
>> +#define CONFIG_NO_LOCK -1
>> +#define CONFIG_INVALID_FILE 3
>> +#define CONFIG_NO_WRITE 4
>> +#define CONFIG_NOTHING_SET 5
>> +#define CONFIG_INVALID_PATTERN 6
> 
> Symbols "CONFIG_FOO" looks too much like they are about the feature set
> chosen when compiling git, at least to me. But I do not think of a better
> naming scheme ("CONFIG_ERR_FOO" may be a slight improvement but not good
> enough improvement for the price we pay by having such long symbol names).

Well, we could do CONFIG_ENOLOCK and such. I didn't find a good sample
to follow. Thinking more about it, using CONFIG_ENOPARSE would be nice,
though I can't decide between 1, 2 or 3 for that...

> By the way, Are you still interested in "diff --stat-count" topic, or have
> you abandoned it?

Yes. I've reworked it a bit but there are three goals:

- count right
- determine the correct maximal file name length
- don't sacrifice efficiency

The middle one is problematic even before my patch (that first loop does
not drop all items that the latter one drops).

Maybe the third one is no real problem so that I could simply go through
the list twice.

Oh, and I've checked that fmt-merge-msg does this:

- output at most <count> items
- if there are more, output "..."

So, there's progress, though not visible yet.

Michael