Dnia środa 1. grudnia 2010 16:09, jari napisał: > On 2010-12-01 15:57, Jakub Narebski wrote: >| On Wed, 1 Dec 2010, Jari Aalto wrote: >|> On 2010-12-01 05:58, Jakub Narebski wrote: >|>| jari.aalto@xxxxxxxxx writes: >|>| >|>|> From: Jari Aalto <jari.aalto@xxxxxxxxx> >|>|> >|>|> >|>|> Signed-off-by: Jari Aalto <jari.aalto@xxxxxxxxx> >|>|> --- >|>|> Documentation/config.txt| 1698 +++++++++++++++++++++++----------------------- >|>|> 1 files changed, 852 insertions(+), 846 deletions(-) >|>| >|>| Why? What such large change is for? >|>| >|>| Note that currently config variables are grouped by functionality: for >|>| example core.eol and core.safecrlf, or core.compression and >|>| core.loosecompression are close to each other. >| >| What about the above? > > We use standard biblical refences: > > Se .... > > Suggest what is needed, and it will be so. Having related config variables together is IMVHO more important than having config variables sorted alphabetically. >|> The phone books have an index where to up information. >|> >|> - When you see script and it use VARIABLE, you look it from >|> manual page >| >| Manpages (and 'git <cmd> --help') are displayed in pager, so you can >| always search for option in a pager (e.g. '/' in 'less', the default >| pager). > > Yuck, it's real fun start backward/forward ping-pong when you dont' > know the directions and can't rely on standard A-Z index. No need for backward/forward, simply go to beginning ([Home]) and search forward (/<pattern>), or go to end ([End]) and search backward (?<pattern>). >|> It is same as putting option in alphabetical order. See GNU cp(1), >|> ssh(1) etc. >| >| In git documentation command line options are not in alphabetical order, >| but grouped by functionality, therefore your argument is invalid. > > I see that only in pages that have tens and tens and tens of options.. And git command doesn't have tens and tens of options? BTW. you discarded my counterexamples of tar, rpm and uname. > > The problem is more the asciidoc's. Various bits and pices are > "included" in place and make ordering the options impossible in some > pages. > > Let's get all pages in shape with A-Z in this regard. That's a good > quality goal. If it is impossible to have options ordered alphabetically because common options are extracted to separate file and then "included", why bother? > >|> There are zillion values and for a reference, alphabetical order makes >|> sense. >| >| I agree that alphabetical order makes sense for glossary; I disagree that >| it makes sense here. > > About 60% in git-config is already in alpha order (core.*, sendmail.* > etc), so there is not really much that is changing. core.* is not in alphabetical order: we have `core.eol', `core.safecrlf', `core.autocrlf'. sendemail.* is not fully in alphabetical order: we have `sendemail.smtpserverport', then `sendemail.smtpserveroption' (p-o, not alphabetical o-p). > Well. If standard reading order is not the standard, I don't know what > is. I'd rather, _if we must_, *generate* gitconfig(5) file with alphabetically ordered configuration variables (and subvariables). Functional grouping is IMVHO more important than alphabetical ordering. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html