git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
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: Sun, 9 May 2010 03:43:25 -0500	[thread overview]
Message-ID: <20100509084325.GA9801@progeny.tock> (raw)
In-Reply-To: <20100509070022.GC23717@sigill.intra.peff.net>

Jeff King wrote:

> Hmm. Both this and 4/8 rewrite bits of the configuration copied from
> config.txt in an earlier patch. Do any changes need to be propagated
> back to config.txt (and no, I didn't read and think carefully, so the
> answer may be "no, they are now diverging intentionally")?

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.

Some divergence is needed imho so that the text can say things like
“see the Options section earlier in this page”.

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.

  CONFIGURATION SECTIONS

  We separate the configuration into <...>.

  Core settings

      [core] (see "Core configuration", below)
          <some blurb about core commands here...>

      [user]
          Default identity to attribute new commits to.

      [url "baseaddress"] (see git-remote(1))
          Short names to use for a long, frequently-used URL.

      [alias] (see "Aliases")
          User-defined git commands that alias other git commands
          with options.

      [gc] (see git-gc(1))
          Automatic repository repacking settings.

      [http] (see git-remote-http(1))
          Tweaking HTTP transport behavior.

      [i18n] (see git-commit(1))
          Commit log encoding and display encoding.

      [notes]
      [notes "rewrite"] (see git-notes(1))
          Display and propagation of commit notes.

      [rerere] (see git-rerere(1))
          Whether to save successful merge resolutions for later
          reuse.

  Output format

      [advice] (see "Advice Options")
          Whether to display optional help messages that may
          dwarf regular output.

      [color] (see "Colored output")
          Which commands should use colored output.

      [color "gitcommand"] (see "Colored output")
          What colors to use for a particular sort of output.  The
          relevant command name is generally the most prominent git
          command which produces that output.

      [format] (see git-log(1))
	  How to display commit metadata by default.  This section is
          shared with git-format-patch(1) configuration.

      [pager] (see "Paginated output")
          Which commands should paginate their output.

  Repository setup

      [branch "branchname"] (see git-branch(1))
          Where `git pull` should pull from for each local branch.

      [remote "reponame"] (see git-remote(1))
          URL and branches for a named remote repository.

      [remotes] (see git-remote(1))
          User-defined collections of remote repositories that are
          often fetched from or pushed to together.

  Helper programs

      [web] (see git-help(1))
          Web browser to use for 'git help --web' and 'git instaweb'.

      [merge "mergedriver"] (see gitattributes(5))
          Low-level format-specific helper for merging files.

      [browser "webbrowser"] (see git-web-browse(1))
          How to invoke a given web browser.

      [man "manpager"] (see git-help(1))
          How to invoke a given man pager.

      [difftool "diffvisualizer"] (see git-difftool(1))
          How to invoke a given diff frontend.

      [mergetool "mergeresolver"] (see git-mergetool(1))
          How to invoke a given interactive 3-way merge helper.

      [guitool "guihelper"] (see git-gui(1))
          How git gui should invoke this helper when selected from
          the "Tools" menu.

  Default behavior of commands

      [add]		git-add(1)
      [am]		git-am(1)
      [apply]		git-apply(1)
      [branch]		git-branch(1)
      [clean]		git-clean(1)
      [commit]		git-commit(1)
      [diff]		git-diff(1)
      [difftool]	git-difftool(1)
      [fetch]		git-fetch-pack(1), git-fetch(1), git-pull(1)
      [format]		git-format-patch(1), git-log(1)
      [gc]		git-gc(1)
      [gitcvs]		git-cvsserver(1)
      [gui]		git-gui(1)
      [help]		git-help(1), git --help
      [imap]		git-imap-send(1)
      [init]		git-init(1)
      [instaweb]	git-instaweb(1)
      [interactive]	git-add--interactive(1), git add -i
      [log]		git-log(1), git-show(1), git-whatchanged(1)
      [mailmap]		git-shortlog(1)
      [man]		git-help(1)
      [merge]		git-merge(1), git-mergetool(1)
      [mergetool]	git-mergetool(1)
      [notes]		git-notes(1)
      [pack]		git-gc(1), git-repack(1)
      [pull]		git-pull(1)
      [push]		git-push(1)
      [receive]		git-receive-pack(1)
      [repack]		git-repack(1)
      [sendemail]	git-send-email(1)
      [sendemail "profile"]
			git-send-email(1)
      [showbranch]	git-show-branch(1)
      [status]		git-status(1)
      [tar]		git-archive(1)
      [transfer]	git-fetch-pack(1), git-receive-pack(1)

  reply	other threads:[~2010-05-09  8:42 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 [this message]
2010-05-10  6:06       ` Jeff King
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=20100509084325.GA9801@progeny.tock \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=peff@peff.net \
    --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).