From: Stephen Boyd Date: Thu, 25 Jun 2009 01:36:31 GMT Subject: Re: [PATCH 2/2] read-tree: migrate to parse-options Message-ID: <4A42D49F.8010805@gmail.com> In-Reply-To: <7vws721ao9.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > Sorry, but I have to ask: Why? I think there are advantages to parse-optification, for plumbing and porcelains. Two reasons I see are: 1. Providing a unified way of handling options 2. Providing a consistent usage message format Obviously, 1 reduces the bugs associated with parsing options (strcmp vs. prefixcmp, incorrect argv+offset). For number 2, I think it helps users when they see the same style of usage messages with each command. It's also nice to get a quick help message without opening the man pages or using git help . Admittedly this patch ends up adding 20 or so lines. Do the above points justify this? I think so. I think the added lines can be attributed to the rougher edges of parse-opts exposed by this patch. You can't take the address of bit fields, so 6 lines are dealing with this problem. Where are the other 15 lines coming from? Looking over it again, I think I may be able to cut the overhead down by refactoring three of the callbacks into boolean options. There's a lot of duplication there, which can be simplified. I was trying to make this a straight port which is probably not so good for convincing you that it's worthwhile. For now, I don't mind this patch being dropped (there's an ambiguity in the callbacks returning non-zero I'd like to fix too). I'll try and get a new patch (or maybe this patch with the oneline fix and a refactoring patch) out later tonight that actually reduces the amount of lines, instead of grossly adding to them.