git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] fetch: add missing documentation
Date: Tue, 24 Sep 2013 02:10:43 -0400	[thread overview]
Message-ID: <20130924061043.GA6678@sigill.intra.peff.net> (raw)
In-Reply-To: <CAMP44s3QfkvXjgmhWPXN7qonbEPpvJFyVm82EBOMSjX7ng3OQg@mail.gmail.com>

On Tue, Sep 24, 2013 at 12:57:36AM -0500, Felipe Contreras wrote:

> No, I'm not. The users that know branch.*.remote exists know why it
> exists. The part where it is explained, 'git config --help', is
> perfectly clear: "When on branch <name>, it tells 'git fetch' and 'git
> push' which remote to fetch from/push to.". So what does
> branch.<name>.remote does, if not precisely what the documentation
> says?
> 
> This is not a rhetorical question, I'm actually expecting you to
> answer, if a user knows that branch.<name>.remote exists, how would
> the above confuse him?

I do not know if by "above" you mean the part of git-config.1 you quoted
above, or the text you are proposing to put into git-fetch.1.

If the former, then I do not think it is confusing at all. The existing
text explains exactly what is going on.

If the latter, then my concern is that the term "upstream branch"
implies implies that "git fetch" depends on branch.*.merge, but it does
not.

> > I was hoping you might suggest something that can help both users by
> > being both precise and giving the appropriate breadcrumbs.
> 
> This is documentation for a Git porcelain command,
> branch.<name>.remote is an implementation detail, and it's irrelevant
> in the documentation at this level.

I don't think it is the end of the world if we say "upstream branch". I
was hoping to find a term that could be both friendly and accurate.

And failing that, I hoped you might say "I see what you are saying, but
I cannot think of a term that is more precise that does not sacrifice
friendliness". But as I seem incapable of even communicating the issue
to you, I'm giving up. It is not worth wasting more time on it.

-Peff

  reply	other threads:[~2013-09-24  6:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-21 14:09 [PATCH 0/2] fetch: trivial fixes Felipe Contreras
2013-09-21 14:09 ` [PATCH 1/2] fetch: add missing documentation Felipe Contreras
2013-09-24  5:03   ` Jeff King
2013-09-24  5:23     ` Felipe Contreras
2013-09-24  5:30       ` Jeff King
2013-09-24  5:36         ` Felipe Contreras
2013-09-24  5:40           ` Jeff King
2013-09-24  5:57             ` Felipe Contreras
2013-09-24  6:10               ` Jeff King [this message]
2013-09-24  6:31                 ` Felipe Contreras
2013-09-24  6:54                   ` Jeff King
2013-09-24  7:41                     ` Felipe Contreras
2013-09-21 14:09 ` [PATCH 2/2] remote: fix trivial memory leak Felipe Contreras
2013-09-24  5:19   ` Jeff King
2013-10-15 21:50     ` Junio C Hamano

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=20130924061043.GA6678@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    /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).