https-github-com-bit
diff --git a/‎Documentation/CodingGuidelines‎
Lines changed: 7 additions & 7 deletions b/‎Documentation/CodingGuidelines‎
Lines changed: 7 additions & 7 deletions
diff --git a/‎Documentation/Makefile‎
Lines changed: 2 additions & 2 deletions b/‎Documentation/Makefile‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎Documentation/SubmittingPatches‎
Lines changed: 5 additions & 5 deletions b/‎Documentation/SubmittingPatches‎
Lines changed: 5 additions & 5 deletions
diff --git a/‎Documentation/blame-options.txt‎
Lines changed: 2 additions & 2 deletions b/‎Documentation/blame-options.txt‎
Lines changed: 2 additions & 2 deletions
@@ -1,5 +1,5 @@
 Like other projects, we also have some guidelines to keep to the
-code.  For git in general, three rough rules are:
+code.  For Git in general, three rough rules are:
 
  - Most importantly, we never say "It's in POSIX; we'll happily
    ignore your needs should your system not conform to it."
@@ -22,7 +22,7 @@ code.  For git in general, three rough rules are:
 As for more concrete guidelines, just imitate the existing code
 (this is a good guideline, no matter which project you are
 contributing to). It is always preferable to match the _local_
-convention. New code added to git suite is expected to match
+convention. New code added to Git suite is expected to match
 the overall style of existing code. Modifications to existing
 code is expected to match the style the surrounding code already
 uses (even if it doesn't match the overall style of existing code).
@@ -112,7 +112,7 @@ For C programs:
 
  - We try to keep to at most 80 characters per line.
 
- - We try to support a wide range of C compilers to compile git with,
+ - We try to support a wide range of C compilers to compile Git with,
    including old ones. That means that you should not use C99
    initializers, even if a lot of compilers grok it.
 
@@ -164,14 +164,14 @@ For C programs:
 
  - If you are planning a new command, consider writing it in shell
    or perl first, so that changes in semantics can be easily
-   changed and discussed.  Many git commands started out like
+   changed and discussed.  Many Git commands started out like
    that, and a few are still scripts.
 
- - Avoid introducing a new dependency into git. This means you
+ - Avoid introducing a new dependency into Git. This means you
    usually should stay away from scripting languages not already
-   used in the git core command set (unless your command is clearly
+   used in the Git core command set (unless your command is clearly
    separate from it, such as an importer to convert random-scm-X
-   repositories to git).
+   repositories to Git).
 
  - When we pass <string, length> pair to functions, we should try to
    pass them in that order.
 
@@ -346,8 +346,8 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
 install-webdoc : html
 	'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)
 
-# You must have a clone of git-htmldocs and git-manpages repositories
-# next to the git repository itself for the following to work.
+# You must have a clone of 'git-htmldocs' and 'git-manpages' repositories
+# next to the 'git' repository itself for the following to work.
 
 quick-install: quick-install-man
 
 
@@ -103,9 +103,9 @@ without external resources. Instead of giving a URL to a mailing list
 archive, summarize the relevant points of the discussion.
 
 
-(3) Generate your patch using git tools out of your commits.
+(3) Generate your patch using Git tools out of your commits.
 
-git based diff tools generate unidiff which is the preferred format.
+Git based diff tools generate unidiff which is the preferred format.
 
 You do not have to be afraid to use -M option to "git diff" or
 "git format-patch", if your patch involves file renames.  The
@@ -122,7 +122,7 @@ that is fine, but please mark it as such.
 
 (4) Sending your patches.
 
-People on the git mailing list need to be able to read and
+People on the Git mailing list need to be able to read and
 comment on the changes you are submitting.  It is important for
 a developer to be able to "quote" your changes, using standard
 e-mail tools, so that they may comment on specific portions of
@@ -244,7 +244,7 @@ then you just add a line saying
 
 	Signed-off-by: Random J Developer <random@developer.example.org>
 
-This line can be automatically added by git if you run the git-commit
+This line can be automatically added by Git if you run the git-commit
 command with the -s option.
 
 Notice that you can place your own Signed-off-by: line when
@@ -337,7 +337,7 @@ Know the status of your patch after submission
   tell you if your patch is merged in pu if you rebase on top of
   master).
 
-* Read the git mailing list, the maintainer regularly posts messages
+* Read the Git mailing list, the maintainer regularly posts messages
   entitled "What's cooking in git.git" and "What's in git.git" giving
   the status of various proposed changes.
 
 
@@ -95,7 +95,7 @@ of lines before or after the line given by <start>.
 	running extra passes of inspection.
 +
 <num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving/copying
+alphanumeric characters that Git must detect as moving/copying
 within a file for it to associate those lines with the parent
 commit. The default value is 20.
 
@@ -110,7 +110,7 @@ commit. The default value is 20.
 	looks for copies from other files in any commit.
 +
 <num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving/copying
+alphanumeric characters that Git must detect as moving/copying
 between files for it to associate those lines with the parent
 commit. And the default value is 40. If there are more than one
 `-C` options given, the <num> argument of the last `-C` will