From: Marc Branchaud <marcnarc@xiplink.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] RelNotes: Spelling & grammar fixes.
Date: Mon, 18 Nov 2013 14:52:54 -0500 [thread overview]
Message-ID: <528A7016.7020307@xiplink.com> (raw)
In-Reply-To: <xmqqmwl1blg7.fsf@gitster.dls.corp.google.com>
On 13-11-18 01:42 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> Mostly just tweaks, although I did change the "foo^{tag}" description a lot.
>
> Thanks. It is surprising that one can make so many typoes in a
> single document ;-)
>
>> @@ -55,7 +55,7 @@ Foreign interfaces, subsystems and ports.
>>
>> * "git-svn" used with SVN 1.8.0 when talking over https:// connection
>> dumped core due to a bug in the serf library that SVN uses. Work
>> - it around on our side, even though the SVN side is being fixed.
>> + around it on our side, even though the SVN side is being fixed.
>
> Hmph, is this a grammo?
I like to call it a "wordo". :)
>> @@ -126,56 +126,58 @@ UI, Workflows & Features
>> "git status --porcelain" instead, as its format is stable and easier
>> to parse.
>>
>> - * Make "foo^{tag}" to peel a tag to itself, i.e. no-op., and fail if
>> - "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" would be
>> - a more convenient way to say "test $(git cat-file -t v1.0) = tag".
>> + * The ref syntax "foo^{tag}" (with the literal string "{tag}") peels a
>> + tag ref to itself, i.e. it's a no-op., and fails if
>> + "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" is
>> + a more convenient way than "test $(git cat-file -t v1.0) = tag" to
>> + check if v1.0 is a tag.
>
> Much easier to read. Thanks.
>
>> * "git branch -v -v" (and "git status") did not distinguish among a
>> - branch that does not build on any other branch, a branch that is in
>> - sync with the branch it builds on, and a branch that is configured
>> - to build on some other branch that no longer exists.
>> + branch that is not tracking any other branch, a branch that is in
>> + sync with the branch it is tracking, and a branch that is tracking
>> + some other branch that no longer exists.
>
> People use the verb "track" to mean too many different things, and
> the original deliberately tried to avoid use of that word.
>
> Specifically, we try to limit the use of "track" to mean "to keep a
> copy of what we observed from the remote" as in "remote-tracking
> branch remotes/origin/master is used to track the 'master' branch at
> your 'origin'", which is very different from "your 'master' branch
> builds on your upstream's 'master'".
>
> So I dunno about this part of the change.
I see.
My initial motivation for the change was that I thought "does not build on"
could too easily be read as "does not compile on".
The change is literally about how branch.<name>.merge configurations are
interpreted. The git-config docs describe that item as "the upstream branch
for the given branch." So maybe we can use "upstream" instead:
* "git branch -v -v" (and "git status") did not distinguish among a
branch that is not based on any upstream branch, a branch that is in
sync with its upstream branch, and a branch that is configured with an
upstream branch that no longer exists.
M.
next prev parent reply other threads:[~2013-11-18 19:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 23:07 [ANNOUNCE] Git v1.8.5-rc2 Junio C Hamano
2013-11-14 16:47 ` Marc Branchaud
2013-11-18 17:01 ` Junio C Hamano
2013-11-18 18:49 ` Junio C Hamano
2013-11-18 19:42 ` Marc Branchaud
2013-11-14 17:01 ` [PATCH] RelNotes: Spelling & grammar fixes Marc Branchaud
2013-11-15 15:26 ` Marc Branchaud
2013-11-18 18:42 ` Junio C Hamano
2013-11-18 19:52 ` Marc Branchaud [this message]
2013-11-18 20:00 ` Jonathan Nieder
2013-11-18 22:12 ` Junio C Hamano
2013-11-18 19:58 ` 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=528A7016.7020307@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).