Re: [PATCH] RelNotes: Spelling & grammar fixes.
Jonathan Nieder writes: > Marc Branchaud wrote: > >> * "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. > > Ooh, this is much nicer than the wording I suggested. > > Thank you. Yup, I'll take this one. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RelNotes: Spelling & grammar fixes.
Marc Branchaud wrote: > * "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. Ooh, this is much nicer than the wording I suggested. Thank you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RelNotes: Spelling & grammar fixes.
Junio C Hamano wrote: > Marc Branchaud writes: >> * "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'". How about something like the following, in the same spirit as --track giving way to --set-upstream-to)? * "git branch -v -v" and "git status" did not distinguish among a branch that does not have a corresponding upstream branch, a branch that is in sync with its upstream, and a branch whose upstream no longer exists. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RelNotes: Spelling & grammar fixes.
On 13-11-18 01:42 PM, Junio C Hamano wrote:
> Marc Branchaud 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..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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RelNotes: Spelling & grammar fixes.
Marc Branchaud 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?
> @@ -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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RelNotes: Spelling & grammar fixes.
Oops: Signed-off-by: Marc Branchaud Sorry! (I have at long last automated s-o-b in my git repo...) M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RelNotes: Spelling & grammar fixes.
---
Mostly just tweaks, although I did change the "foo^{tag}" description a lot.
M.
Documentation/RelNotes/1.8.5.txt | 158 ---
1 file changed, 80 insertions(+), 78 deletions(-)
diff --git a/Documentation/RelNotes/1.8.5.txt b/Documentation/RelNotes/1.8.5.txt
index 13b4336..352dbbb 100644
--- a/Documentation/RelNotes/1.8.5.txt
+++ b/Documentation/RelNotes/1.8.5.txt
@@ -8,7 +8,7 @@ When "git push [$there]" does not say what to push, we have
used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default will change to the "simple"
-semantics that pushes:
+semantics, which pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
@@ -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.
* On MacOS X, we detected if the filesystem needs the "pre-composed
unicode strings" workaround, but did not automatically enable it.
@@ -65,7 +65,7 @@ Foreign interfaces, subsystems and ports.
repository relative to the home directory, e.g. "clone hg::~/there".
* imap-send ported to OS X uses Apple's security framework instead of
- OpenSSL one.
+ OpenSSL's.
* Subversion 1.8.0 that was recently released breaks older subversion
clients coming over http/https in various ways.
@@ -79,22 +79,22 @@ UI, Workflows & Features
* xdg-open can be used as a browser backend for "git web-browse"
(hence to show "git help -w" output), when available.
- * "git grep" and "git show" pays attention to "--textconv" option
+ * "git grep" and "git show" pay attention to the "--textconv" option
when these commands are told to operate on blob objects (e.g. "git
- grep -e pattern HEAD:Makefile").
+ grep -e pattern --textconv HEAD:Makefile").
* "git replace" helper no longer allows an object to be replaced with
another object of a different type to avoid confusion (you can
- still manually craft such replacement using "git update-ref", as an
+ still manually craft such a replacement using "git update-ref", as an
escape hatch).
- * "git status" no longer prints dirty status information for
+ * "git status" no longer prints the dirty status information of
submodules for which submodule.$name.ignore is set to "all".
* "git rebase -i" honours core.abbrev when preparing the insn sheet
for editing.
- * "git status" during a cherry-pick shows what original commit is
+ * "git status" during a cherry-pick shows which original commit is
being picked.
* Instead of typing four capital letters "HEAD", you can say "@" now,
@@ -102,21 +102,21 @@ UI, Workflows & Features
* "git check-ignore" follows the same rule as "git add" and "git
status" in that the ignore/exclude mechanism does not take effect
- on paths that are already tracked. With "--no-index" option, it
+ on paths that are already tracked. With the "--no-index" option, it
can be used to diagnose which paths that should have been ignored
have been mistakenly added to the index.
* Some irrelevant "advice" messages that are shared with "git status"
output have been removed from the commit log template.
- * "update-refs" learnt a "--stdin" option to read multiple update
+ * "update-refs" learned a "--stdin" option to read multiple update
requests and perform them in an all-or-none fashion.
* Just like "make -C ", "git -C ..." tells Git
to go there before doing anything else.
- * Just like "git checkout -" knows to check out and "git merge -"
- knows to merge the branch you were previously on, "git cherry-pick"
+ * Just like "git checkout -" knows to check out, and "git merge -"
+ knows to merge, the branch you were previously on, "git cherry-pick"
now understands "git cherry-pick -" to pick from the previous
branch.
@@ -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.
* "git branch -v -v" (and "git status") did not distinguish among a
- branch tha
