Re: [PATCH] git-fast-import(1): reorganise options
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 6, 2013, 23:10 UTC
- Message-ID
- <7va9slnc07.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130106142825.GH6440@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
Show 16 quoted lines
> On Sun, Jan 06, 2013 at 05:51:09AM -0800, Jonathan Nieder wrote: > ... >> Nice description. >> >> > While doing this, fix the duplicate '--done' documentation by taking the >> > best bits of each. Also combine the descriptions of '--relative-marks' >> > and '--no-relative-marks' since they make more sense together. >> >> I'd prefer to keep those as separate patches, if that's manageable. > > I'll send a series of three patches if the discussion below seems > reasonable: > > [1/3] remove duplicate '--done' > [2/3] combine --[no-]relative-marks > [3/3] reorganize options
Sounds sensible and I like the direction in which this discussion is progressing.
Show 13 quoted lines
>> I'd worry that the catch-all toplevel category would grow larger >> and larger with time, since it's the obvious place to put any new >> option. > > I agree that that's a concern, perhaps '--cat-blob-fd' should be > combined with '--date-format' and '--done' into a section called > "Options for frontends" or similar? > > And maybe '--export-pack-edges' can move to the performance/compression > tuning section? I expect the interested audience would be the same. > > That only leaves three options in that section, which seems more > reasonable.
I'll leave it to others to decide which individual options would fall into that catch-all category, but the idea you outlined above sounds sensible overall.
Show 6 quoted lines
> I realise it's personal taste, but I like the subheadings of the form > "Options (for|related to) ...", so maybe: > > Options for input stream features > Options related to marks files > Options for performance and compression tuning
Again, sounds sensible.
Show 8 quoted lines
>> I like how you put important options like --force on top. Perhaps >> the less important --quiet and --stats could be split off from that >> into a subsection like "Verbosity" to make them stand out even more. > > I quite like having the verbosity options near the top since those are > the ones that are most likely to be of interest to a user, whereas the > rest are likely to be prescribed by the frontend (or only really useful > to frontend authors).
I tend to agree with Jonathan that verbosity options are less important ones than the ones that affect how things work.
Thanks.