git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).