Re: [RFC/WIP 0/2] Documentation clean-up: git commands

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

Junio C Hamano venit, vidit, dixit 23.03.2009 17:22:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> - Do we want it this way (`git command`)?
> 
> That's my personal preference but other people may differ; wasn't there an
> issue with "man" backend losing the typesetting information?

Some man readers reconstruct links when they see something like
git-add[1], which is why I proposed not changing those for now. A while
ago I introduced a backend specific linkgit macro (git-command for man,
git command for others), but that was not so well received.

>> - How to prepare: 1 patch per file/per 5 files/per 50 changes?
>> - How to submit: single patch once ready or whole series at end (5 years
>>   from now)?
>> - How to send: Bother the list or send pull requests only?
> 
> How about a fork of git.git on repo.or.cz that branches from 1.6.2 and that:
> 
>  - does not pull from git.git/master unless absoletely necessary; and
>  - contains only these clean-up changes and nothing else?
>

Whatever works for you. I have a fork there anyway but would need to
rebase to 1.6.2 as opposed to next. But somehow we would need to ensure
that new Documentation patches don't regress away from the consistent style.

> A bonus point would be for a publically reachable pages rendered out of
> the tip of this "documentation updates" repository, so that people can
> view it, compare it with www.kernel.org/pub/software/git/docs/.

I didn't plan on changing style, only making the usage of ` and such
more consistent. I find these are spotted most conveniently with diff
--color-words. Do you really think rendered versions are worthwhile for
that?

> I would love to have a separate "documentation maintainer" in the longer
> run, and it would be great if your tree becomes it.  I can start pulling
> from you, forwarding any documentation patches your way.
> 
> Thanks.

Uhm, ohm. Let's see how the quotation and dash thing goes first... I
don't want to make promises I can't keep (time-wise).

Michael