git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 23, 2009, 16:35 UTC
Message-ID
<49C7BA5F.9090600@drmicha.warpmail.net>
In-Reply-To
<7vwsag5hva.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 23.03.2009 17:22:
Show 6 quoted lines
> 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.

Show 10 quoted lines
>> - 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?

Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Chris Johnsen
Message 8 of 11 in “[RFC/WIP 0/2] Documentation clean-up: git commands”
  1. Michael J GruberMar 23, 2009
  2. 1/2 Documentation: fix minor inconsistencyMichael J Gruber, Mar 23, 2009
  3. 2/2 Documentation: format git commands consistentlyMichael J Gruber, Mar 23, 2009
  4. Matthieu MoyMar 23, 2009
  5. Michael J GruberMar 23, 2009
  6. Michael J GruberMar 23, 2009
  7. Junio C HamanoMar 23, 2009
  8. Michael J GruberMar 23, 2009
  9. Chris JohnsenMar 23, 2009
  10. Jeff KingMar 24, 2009
  11. Michael J GruberMar 24, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.