48a8c26c62 · matheusbsbs/matheus-bagliano

Documentation/CodingGuidelines

+5

@@ -230,3 +230,8 @@ Writing Documentation:

230 valid usage. "*" has its own pair of brackets, because it can

231 (optionally) be specified only when one or more of the letters is

232 also provided.

233 +

234 + A note on notation:

235 + Use 'git' (all lowercase) when talking about commands i.e. something

236 + the user would type into a shell and use 'Git' (uppercase first letter)

237 + when talking about the version control system and its properties.

Documentation/SubmittingPatches

+1 -1

@@ -206,7 +206,7 @@ patch.

206

207 To improve tracking of who did what, we've borrowed the

208 "sign-off" procedure from the Linux kernel project on patches

209 -that are being emailed around. Although core GIT is a lot

209 +that are being emailed around. Although core Git is a lot

210 smaller project it is a good discipline to follow it.

211

212 The sign-off is a simple line at the end of the explanation for

Documentation/asciidoc.conf

+1 -1

@@ -4,7 +4,7 @@

4 #

5 # Note, {0} is the manpage section, while {target} is the command.

6 #

7 -# Show GIT link as: <command>(<section>); if section is defined, else just show

7 +# Show Git link as: <command>(<section>); if section is defined, else just show

8 # the command.

9

10 [macros]

Documentation/everyday.txt

+2 -2

@@ -1,4 +1,4 @@

1 -Everyday GIT With 20 Commands Or So

1 +Everyday Git With 20 Commands Or So

2 ===================================

3

4 <<Individual Developer (Standalone)>> commands are essential for

@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.

229 Examples

230 ~~~~~~~~

231

232 -My typical GIT day.::

232 +My typical Git day.::

233 +

234 ------------

235 $ git status <1>

Documentation/git-clone.txt

+1 -1

@@ -125,7 +125,7 @@ objects from the source repository into a pack in the cloned repository.

125 No checkout of HEAD is performed after the clone is complete.

126

127 --bare::

128 - Make a 'bare' GIT repository. That is, instead of

128 + Make a 'bare' Git repository. That is, instead of

129 creating `<directory>` and placing the administrative

130 files in `<directory>/.git`, make the `<directory>`

131 itself the `$GIT_DIR`. This obviously implies the `-n`

Documentation/git-cvsexportcommit.txt

+1 -1

@@ -15,7 +15,7 @@ SYNOPSIS

15

16 DESCRIPTION

17 -----------

18 -Exports a commit from GIT to a CVS checkout, making it easier

18 +Exports a commit from Git to a CVS checkout, making it easier

19 to merge patches from a git repository into a CVS repository.

20

21 Specify the name of a CVS checkout using the -w switch or execute it

Documentation/git-cvsserver.txt

+4 -4

@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these clients.

72 LIMITATIONS

73 -----------

74

75 -CVS clients cannot tag, branch or perform GIT merges.

75 +CVS clients cannot tag, branch or perform Git merges.

76

77 -'git-cvsserver' maps GIT branches to CVS modules. This is very different

77 +'git-cvsserver' maps Git branches to CVS modules. This is very different

78 from what most CVS users would expect since in CVS modules usually represent

79 one or more directories.

80

@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for example:

130 ------

131 cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>

132 ------

133 -No special setup is needed for SSH access, other than having GIT tools

133 +No special setup is needed for SSH access, other than having Git tools

134 in the PATH. If you have clients that do not accept the CVS_SERVER

135 environment variable, you can rename 'git-cvsserver' to `cvs`.

136

@@ -197,7 +197,7 @@ allowing access over SSH.

197 shell is bash, .bashrc may be a reasonable alternative.

198

199 5. Clients should now be able to check out the project. Use the CVS 'module'

200 - name to indicate what GIT 'head' you want to check out. This also sets the

200 + name to indicate what Git 'head' you want to check out. This also sets the

201 name of your newly checked-out directory, unless you tell it otherwise with

202 `-d <dir_name>`. For example, this checks out 'master' branch to the

203 `project-master` directory:

Documentation/git-daemon.txt

+2 -2

@@ -51,7 +51,7 @@ OPTIONS

51

52 --base-path=<path>::

53 Remap all the path requests as relative to the given path.

54 - This is sort of "GIT root" - if you run 'git daemon' with

54 + This is sort of "Git root" - if you run 'git daemon' with

55 '--base-path=/srv/git' on example.com, then if you later try to pull

56 'git://example.com/hello.git', 'git daemon' will interpret the path

57 as '/srv/git/hello.git'.

@@ -73,7 +73,7 @@ OPTIONS

73 whitelist.

74

75 --export-all::

76 - Allow pulling from all directories that look like GIT repositories

76 + Allow pulling from all directories that look like Git repositories

77 (have the 'objects' and 'refs' subdirectories), even if they

78 do not have the 'git-daemon-export-ok' file.

79

Documentation/git-mv.txt

+1 -1

@@ -34,7 +34,7 @@ OPTIONS

34 -k::

35 Skip move or rename actions which would lead to an error

36 condition. An error happens when a source is neither existing nor

37 - controlled by GIT, or when it would overwrite an existing

37 + controlled by Git, or when it would overwrite an existing

38 file unless '-f' is given.

39 -n::

40 --dry-run::

Documentation/git-send-email.txt

+1 -1

@@ -67,7 +67,7 @@ The --cc option must be repeated for each user you want on the cc list.

67 When '--compose' is used, git send-email will use the From, Subject, and

68 In-Reply-To headers specified in the message. If the body of the message

69 (what you type after the headers and a blank line) only contains blank

70 -(or GIT: prefixed) lines the summary won't be sent, but From, Subject,

70 +(or Git: prefixed) lines the summary won't be sent, but From, Subject,

71 and In-Reply-To headers will be used unless they are removed.

72 +

73 Missing From or In-Reply-To headers will be prompted for.

Documentation/git-tools.txt

+7 -7

@@ -19,24 +19,24 @@ Alternative/Augmentative Porcelains

19

20 Cogito is a version control system layered on top of the git tree history

21 storage system. It aims at seamless user interface and ease of use,

22 - providing generally smoother user experience than the "raw" Core GIT

22 + providing generally smoother user experience than the "raw" Core Git

23 itself and indeed many other version control systems.

24

25 Cogito is no longer maintained as most of its functionality

26 - is now in core GIT.

26 + is now in core Git.

27

28

29 - *pg* (http://www.spearce.org/category/projects/scm/pg/)

30

31 - pg is a shell script wrapper around GIT to help the user manage a set of

31 + pg is a shell script wrapper around Git to help the user manage a set of

32 patches to files. pg is somewhat like quilt or StGIT, but it does have a

33 slightly different feature set.

34

35

36 - *StGit* (http://www.procode.org/stgit/)

37

38 - Stacked GIT provides a quilt-like patch management functionality in the

39 - GIT environment. You can easily manage your patches in the scope of GIT

38 + Stacked Git provides a quilt-like patch management functionality in the

39 + Git environment. You can easily manage your patches in the scope of Git

40 until they get merged upstream.

41

42

@@ -45,7 +45,7 @@ History Viewers

45

46 - *gitk* (shipped with git-core)

47

48 - gitk is a simple Tk GUI for browsing history of GIT repositories easily.

48 + gitk is a simple Tk GUI for browsing history of Git repositories easily.

49

50

51 - *gitview* (contrib/)

@@ -55,7 +55,7 @@ History Viewers

55

56 - *gitweb* (shipped with git-core)

57

58 - GITweb provides full-fledged web interface for GIT repositories.

58 + Gitweb provides full-fledged web interface for Git repositories.

59

60

61 - *qgit* (http://digilander.libero.it/mcostalba/)

Documentation/git-update-ref.txt

+1 -1

@@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:

73 Where "oldsha1" is the 40 character hexadecimal value previously

74 stored in <ref>, "newsha1" is the 40 character hexadecimal value of

75 <newvalue> and "committer" is the committer's name, email address

76 -and date in the standard GIT committer ident format.

76 +and date in the standard Git committer ident format.

77

78 Optionally with -m:

79

Documentation/git.txt

+1 -1

@@ -890,7 +890,7 @@ See also the link:howto-index.html[howto] documents for some useful

890 examples.

891

892 The internals are documented in the

893 -link:technical/api-index.html[GIT API documentation].

893 +link:technical/api-index.html[Git API documentation].

894

895 Users migrating from CVS may also want to

896 read linkgit:gitcvs-migration[7].

Documentation/gitcore-tutorial.txt

+2 -2

@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git commands to set up and

16 work with a git repository.

17

18 If you just need to use git as a revision control system you may prefer

19 -to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or

20 -link:user-manual.html[the GIT User Manual].

19 +to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or

20 +link:user-manual.html[the Git User Manual].

21

22 However, an understanding of these low-level tools can be helpful if

23 you want to understand git's internals.

Documentation/gitglossary.txt

+1 -1

@@ -3,7 +3,7 @@ gitglossary(7)

3

4 NAME

5 ----

6 -gitglossary - A GIT Glossary

6 +gitglossary - A Git Glossary

7

8 SYNOPSIS

9 --------

Documentation/gittutorial.txt

+1 -1

@@ -656,7 +656,7 @@ digressions that may be interesting at this point are:

656 * linkgit:gitworkflows[7]: Gives an overview of recommended

657 workflows.

658

659 - * link:everyday.html[Everyday GIT with 20 Commands Or So]

659 + * link:everyday.html[Everyday Git with 20 Commands Or So]

660

661 * linkgit:gitcvs-migration[7]: Git for CVS users.

662

Documentation/gitweb.txt

+1 -1

@@ -504,7 +504,7 @@ repositories, you can configure Apache like this:

504

505 The above configuration expects your public repositories to live under

506 '/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`,

507 -both as cloneable GIT URL and as browseable gitweb interface. If you then

507 +both as cloneable Git URL and as browseable gitweb interface. If you then

508 start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`

509 then you can even use the `git://` URL with exactly the same path.

510

Documentation/gitworkflows.txt

+1 -1

@@ -242,7 +242,7 @@ tag to the tip of 'master' indicating the release version:

242 .Release tagging

243 [caption="Recipe: "]

244 =====================================

245 -`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`

245 +`git tag -s -m "Git X.Y.Z" vX.Y.Z master`

246 =====================================

247

248 You need to push the new tag to a public git server (see

Documentation/glossary-content.txt

+1 -1

@@ -52,7 +52,7 @@

52 [[def_cherry-picking]]cherry-picking::

53 In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of

54 changes out of a series of changes (typically commits) and record them

55 - as a new series of changes on top of a different codebase. In GIT, this is

55 + as a new series of changes on top of a different codebase. In Git, this is

56 performed by the "git cherry-pick" command to extract the change introduced

57 by an existing <<def_commit,commit>> and to record it based on the tip

58 of the current <<def_branch,branch>> as a new commit.

Documentation/howto-index.sh

+1 -1

@@ -1,7 +1,7 @@

1 #!/bin/sh

2

3 cat <<\EOF

4 -GIT Howto Index

4 +Git Howto Index

5 ===============

6

7 Here is a collection of mailing list postings made by various

Documentation/howto/rebase-from-internal-branch.txt

+3 -3

@@ -4,7 +4,7 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>

4 Subject: Re: sending changesets from the middle of a git tree

5 Date: Sun, 14 Aug 2005 18:37:39 -0700

6 Abstract: In this article, JC talks about how he rebases the

7 - public "pu" branch using the core GIT tools when he updates

7 + public "pu" branch using the core Git tools when he updates

8 the "master" branch, and how "rebase" works. Also discussed

9 is how this applies to individual developers who sends patches

10 upstream.

@@ -31,7 +31,7 @@ up. With its basing philosophical ancestry on quilt, this is

31 the kind of task StGIT is designed to do.

32

33 I just have done a simpler one, this time using only the core

34 -GIT tools.

34 +Git tools.

35

36 I had a handful of commits that were ahead of master in pu, and I

37 wanted to add some documentation bypassing my usual habit of

@@ -96,7 +96,7 @@ you ran fsck-cache, which is normal. After testing "pu", you

96 can run "git prune" to get rid of those original three commits.

97

98 While I am talking about "git rebase", I should talk about how

99 -to do cherrypicking using only the core GIT tools.

99 +to do cherrypicking using only the core Git tools.

100

101 Let's go back to the earlier picture, with different labels.

102

Documentation/howto/revert-branch-rebase.txt

+2 -2

@@ -12,10 +12,10 @@ How to revert an existing commit

12 ================================

13

14 One of the changes I pulled into the 'master' branch turns out to

15 -break building GIT with GCC 2.95. While they were well intentioned

15 +break building Git with GCC 2.95. While they were well intentioned

16 portability fixes, keeping things working with gcc-2.95 was also

17 important. Here is what I did to revert the change in the 'master'

18 -branch and to adjust the 'pu' branch, using core GIT tools and

18 +branch and to adjust the 'pu' branch, using core Git tools and

19 barebone Porcelain.

20

21 First, prepare a throw-away branch in case I screw things up.

Documentation/howto/setup-git-server-over-http.txt

+2 -2

@@ -53,10 +53,10 @@ In effect, this means you're going to be root, or that you're using a

53 preconfigured WebDAV server.

54

55

56 -Step 1: setup a bare GIT repository

56 +Step 1: setup a bare Git repository

57 -----------------------------------

58

59 -At the time of writing, git-http-push cannot remotely create a GIT

59 +At the time of writing, git-http-push cannot remotely create a Git

60 repository. So we have to do that at the server side with git. Another

61 option is to generate an empty bare repository at the client and copy

62 it to the server with a WebDAV client (which is the only option if Git

Documentation/technical/api-index-skel.txt

+2 -2

@@ -1,7 +1,7 @@

1 -GIT API Documents

1 +Git API Documents

2 =================

3

4 -GIT has grown a set of internal API over time. This collection

4 +Git has grown a set of internal API over time. This collection

5 documents them.

6

7 ////////////////////////////////////////////////////////////////

Documentation/technical/index-format.txt

+3 -3

@@ -1,4 +1,4 @@

1 -GIT index format

1 +Git index format

2 ================

3

4 == The git index file has the following format

@@ -21,9 +21,9 @@ GIT index format

21 - Extensions

22

23 Extensions are identified by signature. Optional extensions can

24 - be ignored if GIT does not understand them.

24 + be ignored if Git does not understand them.

25

26 - GIT currently supports cached tree and resolve undo extensions.

26 + Git currently supports cached tree and resolve undo extensions.

27

28 4-byte extension signature. If the first byte is 'A'..'Z' the

29 extension is optional and can be ignored.

Documentation/technical/pack-format.txt

+2 -2

@@ -1,4 +1,4 @@

1 -GIT pack format

1 +Git pack format

2 ===============

3

4 == pack-*.pack files have the following format:

@@ -9,7 +9,7 @@ GIT pack format

9 The signature is: {'P', 'A', 'C', 'K'}

10

11 4-byte version number (network byte order):

12 - GIT currently accepts version number 2 or 3 but

12 + Git currently accepts version number 2 or 3 but

13 generates version 2 only.

14

15 4-byte number of objects contained in the pack (network byte order)

Documentation/user-manual.txt

+2 -2

@@ -2299,7 +2299,7 @@ Here are some of the scripts that simplify all this even further.

2299

2300 -------------------------------------------------

2301 ==== update script ====

2302 -# Update a branch in my GIT tree. If the branch to be updated

2302 +# Update a branch in my Git tree. If the branch to be updated

2303 # is origin, then pull from kernel.org. Otherwise merge

2304 # origin/master branch into test|release branch

2305

@@ -2357,7 +2357,7 @@ esac

2357

2358 -------------------------------------------------

2359 ==== status script ====

2360 -# report on status of my ia64 GIT tree

2360 +# report on status of my ia64 Git tree

2361

2362 gb=$(tput setab 2)

2363 rb=$(tput setab 1)

README

+1 -1

@@ -1,6 +1,6 @@

1 ////////////////////////////////////////////////////////////////

2

3 - GIT - the stupid content tracker

3 + Git - the stupid content tracker

4

5 ////////////////////////////////////////////////////////////////

6

Documentation: avoid poor-man's small caps GIT