From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
Thomas Rast <trast@student.ethz.ch>
Subject: Re: [PATCH 6/8] Documentation/notes: simplify treatment of default display refs
Date: Mon, 10 May 2010 02:06:30 -0400 [thread overview]
Message-ID: <20100510060630.GC13340@coredump.intra.peff.net> (raw)
In-Reply-To: <20100509084325.GA9801@progeny.tock>
On Sun, May 09, 2010 at 03:43:25AM -0500, Jonathan Nieder wrote:
> Thanks for bringing this up. I think some of the changes ultimately
> ought to be propagated back to config.txt. I copied the text anyway
> because as long as the differences are in short-term memory, I find it
> easier to manipulate two similar files than one file with ifdefs in
> it; so it seemed like a reasonable strategy to let these diverge for a
> few weeks and then merge them with ifdefs again.
Hrm. If that merge actually happens while things are still in short-term
memory. ;)
> Some divergence is needed imho so that the text can say things like
> “see the Options section earlier in this page”.
Yeah, understandable. And I also don't want to get into a rat's nest of
ifdefs in the documentation. Which is why I was pushing to move straight
into something more elegant. :)
> Longer term, I suspect I would like a gitconfig.5 page that functioned
> something like the main commands list, which could avoid some
> duplication. But this is something to be considered carefully: right
> now it is very easy to start with knowing there is some configuration
> for what you want to change (conflict hunk format, say) and find it by
> searching the descriptions in git-config.1; if we split that file up,
> that won’t be so easy.
Yeah, I do worry about people being able to search effectively. But to
some degree, sensible naming of the options helps with that. Searching
for "conflict" even in just a list of options should come up with
"merge.conflictstyle", and I had always intended for such a gitconfig.5
to have a full list.
> CONFIGURATION SECTIONS
> [...]
Your breakdown looks like a sensible thing to have at the start of
gitconfig.5. It looks like you were planning on putting some generic
concepts like "alias" and "core" into that page (at the end of the
overview list), and then referring to individual command pages for their
respective sections. That sounds reasonable to me.
-Peff
next prev parent reply other threads:[~2010-05-10 6:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-09 3:13 [PATCH v2 0/8] filling out the notes man page Jonathan Nieder
2010-05-09 3:19 ` [PATCH 1/8] Documentation/notes: document format of notes trees Jonathan Nieder
2010-05-09 6:52 ` Jeff King
2010-05-09 3:21 ` [PATCH 2/8] Documentation/notes: describe content of notes blobs Jonathan Nieder
2010-05-09 3:21 ` [PATCH 3/8] Documentation/notes: add configuration section Jonathan Nieder
2010-05-09 3:23 ` [PATCH 4/8] Documentation/notes: simplify treatment of default notes ref Jonathan Nieder
2010-05-12 7:46 ` Thomas Rast
2010-05-12 10:28 ` Jonathan Nieder
2010-05-09 3:30 ` [PATCH 5/8] Documentation/log: add a CONFIGURATION section Jonathan Nieder
2010-05-09 6:57 ` Jeff King
2010-05-09 3:32 ` [PATCH 6/8] Documentation/notes: simplify treatment of default display refs Jonathan Nieder
2010-05-09 7:00 ` Jeff King
2010-05-09 8:43 ` Jonathan Nieder
2010-05-10 6:06 ` Jeff King [this message]
2010-05-12 10:50 ` Jonathan Nieder
2010-05-12 11:23 ` Jeff King
2010-05-09 3:33 ` [PATCH 7/8] Documentation/notes: clean up description of rewriting configuration Jonathan Nieder
2010-05-09 3:37 ` [PATCH 8/8] Documentation/notes: nitpicks Jonathan Nieder
2010-05-10 23:27 ` [PATCH v2 0/8] filling out the notes man page Johan Herland
2010-05-12 7:48 ` Thomas Rast
2010-05-12 12:57 ` [PATCH v3] Documentation/notes: fill out the man page a little Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100510060630.GC13340@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=jrnieder@gmail.com \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).