git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 1/3] doc: provide guidance on user.name format
Date: Fri, 18 Oct 2019 01:37:17 -0400	[thread overview]
Message-ID: <20191018053716.GA18384@sigill.intra.peff.net> (raw)
In-Reply-To: <20191017222038.t2qlqderp44q2m7v@camp.crustytoothpaste.net>

On Thu, Oct 17, 2019 at 10:20:38PM +0000, brian m. carlson wrote:

> > >  Documentation/git-commit-tree.txt | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > 
> > ...I was surprised to see it here, where I think most users wouldn't
> > find it. Would it make sense in git-commit(1), or in the description of
> > the user.name config?
> 
> So the user.name config description points to git-commit-tree(1), which
> describes these in detail, which is why I put it there.  I agree that
> it's not a super discoverable place, since I don't know anyone that
> actually uses git commit-tree these days.  git-commit(1) doesn't
> describe these options at all.

Hmm, yeah. It's a little funny to point users at git-commit-tree, I
think. Some of that documentation may go better in git-commit. But
resolving that may be more than you want to bite off right now.

> There are, of course, options.  I can add this text into the `user.name`
> option in git-config(5) nevertheless, which will likely be more
> discoverable, but it will split the documentation on those into two
> separate locations.  Or we can leave it in git-commit-tree(1) anyway to
> keep it together.

I like the idea of mentioning something about it in user.name, even if
it's more brief ("Note that this doesn't impact the username used for
network authentication; see credential.username" or something).

-Peff

  reply	other threads:[~2019-10-18  5:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17  0:53 [PATCH v2 0/3] Documentation for common user misconceptions brian m. carlson
2019-10-17  0:53 ` [PATCH v2 1/3] doc: provide guidance on user.name format brian m. carlson
2019-10-17  5:40   ` Jeff King
2019-10-17  7:39     ` Junio C Hamano
2019-10-17 22:20     ` brian m. carlson
2019-10-18  5:37       ` Jeff King [this message]
2019-10-17  0:53 ` [PATCH v2 2/3] doc: dissuade users from trying to ignore tracked files brian m. carlson
2019-10-17  5:44   ` Jeff King
2019-10-17  0:53 ` [PATCH v2 3/3] docs: mention when increasing http.postBuffer is valuable brian m. carlson
2019-10-17  5:52   ` Jeff King

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=20191018053716.GA18384@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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).