6a5d0b0a90 · matheusbsbs/matheus-bagliano

Documentation/diff-format.txt

+1 -1

@@ -19,7 +19,7 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::

19 git-diff-files [<pattern>...]::

20 compares the index and the files on the filesystem.

21

22 -The "git-diff-tree" command begins its ouput by printing the hash of

22 +The "git-diff-tree" command begins its output by printing the hash of

23 what is being compared. After that, all the commands print one output

24 line per changed file.

25

Documentation/git-bisect-lk2009.txt

+1 -1

@@ -799,7 +799,7 @@ fixed in the "main" branch by commit "F"?

799 The result of such a bisection would be that we would find that H is

800 the first bad commit, when in fact it's B. So that would be wrong!

801

802 -And yes it's can happen in practice that people working on one branch

802 +And yes it can happen in practice that people working on one branch

803 are not aware that people working on another branch fixed a bug! It

804 could also happen that F fixed more than one bug or that it is a

805 revert of some big development effort that was not ready to be

Documentation/git-fast-export.txt

+1 -1

@@ -37,7 +37,7 @@ unsigned, with 'verbatim', they will be silently exported

37 and with 'warn', they will be exported, but you will see a warning.

38

39 --tag-of-filtered-object=(abort|drop|rewrite)::

40 - Specify how to handle tags whose tagged objectis filtered out.

40 + Specify how to handle tags whose tagged object is filtered out.

41 Since revisions and files to export can be limited by path,

42 tagged objects may be filtered completely.

43 +

Documentation/git-fast-import.txt

+4 -4

@@ -152,7 +152,7 @@ fast-forward update, fast-import will skip updating that ref and instead

152 prints a warning message. fast-import will always attempt to update all

153 branch refs, and does not stop on the first failure.

154

155 -Branch updates can be forced with \--force, but its recommended that

155 +Branch updates can be forced with \--force, but it's recommended that

156 this only be used on an otherwise quiet repository. Using \--force

157 is not necessary for an initial import into an empty repository.

158

@@ -267,7 +267,7 @@ is always copied into the identity string at the time it is being

267 created by fast-import. There is no way to specify a different time or

268 timezone.

269 +

270 -This particular format is supplied as its short to implement and

270 +This particular format is supplied as it's short to implement and

271 may be useful to a process that wants to create a new commit

272 right now, without needing to use a working directory or

273 'git update-index'.

@@ -420,7 +420,7 @@ quoting or escaping syntax is supported within `<committish>`.

420 Here `<committish>` is any of the following:

421

422 * The name of an existing branch already in fast-import's internal branch

423 - table. If fast-import doesn't know the name, its treated as a SHA-1

423 + table. If fast-import doesn't know the name, it's treated as a SHA-1

424 expression.

425

426 * A mark reference, `:<idnum>`, where `<idnum>` is the mark number.

@@ -759,7 +759,7 @@ assigned mark.

759

760 The mark command is optional here as some frontends have chosen

761 to generate the Git SHA-1 for the blob on their own, and feed that

762 -directly to `commit`. This is typically more work than its worth

762 +directly to `commit`. This is typically more work than it's worth

763 however, as marks are inexpensive to store and easy to use.

764

765 `data`

Documentation/git-http-backend.txt

+1 -1

@@ -14,7 +14,7 @@ DESCRIPTION

14 -----------

15 A simple CGI program to serve the contents of a Git repository to Git

16 clients accessing the repository over http:// and https:// protocols.

17 -The program supports clients fetching using both the smart HTTP protcol

17 +The program supports clients fetching using both the smart HTTP protocol

18 and the backwards-compatible dumb HTTP protocol, as well as clients

19 pushing using the smart HTTP protocol.

20

Documentation/git-remote-helpers.txt

+1 -1

@@ -25,7 +25,7 @@ Commands are given by the caller on the helper's standard input, one per line.

25

26 'capabilities'::

27 Lists the capabilities of the helper, one per line, ending

28 - with a blank line. Each capability may be preceeded with '*'.

28 + with a blank line. Each capability may be preceded with '*'.

29 This marks them mandatory for git version using the remote

30 helper to understand (unknown mandatory capability is fatal

31 error).

Documentation/git-rev-parse.txt

+1 -1

@@ -33,7 +33,7 @@ OPTIONS

33 --stop-at-non-option::

34 Only meaningful in `--parseopt` mode. Lets the option parser stop at

35 the first non-option argument. This can be used to parse sub-commands

36 - that take options themself.

36 + that take options themselves.

37

38 --sq-quote::

39 Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE

Documentation/git-submodule.txt

+1 -1

@@ -218,7 +218,7 @@ OPTIONS

218 This option is only valid for the update command.

219 Rebase the current branch onto the commit recorded in the

220 superproject. If this option is given, the submodule's HEAD will not

221 - be detached. If a a merge failure prevents this process, you will have

221 + be detached. If a merge failure prevents this process, you will have

222 to resolve these failures with linkgit:git-rebase[1].

223 If the key `submodule.$name.update` is set to `rebase`, this option is

224 implicit.

Documentation/rev-list-options.txt

+4 -4

@@ -233,27 +233,27 @@ endif::git-rev-list[]

233 Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed

234 on the command line as '<commit>'. If `pattern` is given, limit

235 branches to ones matching given shell glob. If pattern lacks '?',

236 - '*', or '[', '/*' at the end is impiled.

236 + '*', or '[', '/*' at the end is implied.

237

238 --tags[=pattern]::

239

240 Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed

241 on the command line as '<commit>'. If `pattern` is given, limit

242 tags to ones matching given shell glob. If pattern lacks '?', '*',

243 - or '[', '/*' at the end is impiled.

243 + or '[', '/*' at the end is implied.

244

245 --remotes[=pattern]::

246

247 Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed

248 on the command line as '<commit>'. If `pattern`is given, limit

249 remote tracking branches to ones matching given shell glob.

250 - If pattern lacks '?', '*', or '[', '/*' at the end is impiled.

250 + If pattern lacks '?', '*', or '[', '/*' at the end is implied.

251

252 --glob=glob-pattern::

253 Pretend as if all the refs matching shell glob `glob-pattern`

254 are listed on the command line as '<commit>'. Leading 'refs/',

255 is automatically prepended if missing. If pattern lacks '?', '*',

256 - or '[', '/*' at the end is impiled.

256 + or '[', '/*' at the end is implied.

257

258

259 ifndef::git-rev-list[]

Documentation/technical/api-run-command.txt

+1 -1

@@ -51,7 +51,7 @@ The functions above do the following:

51 ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.

52

53 . Otherwise, the program is run. If it terminates regularly, its exit

54 - code is returned. No diagnistic is printed, even if the exit code is

54 + code is returned. No diagnostic is printed, even if the exit code is

55 non-zero.

56

57 . If the program terminated due to a signal, then the return value is the

Documentation/technical/pack-protocol.txt

+5 -5

@@ -149,7 +149,7 @@ advertisement list at all, but other refs may still appear.

149 The stream MUST include capability declarations behind a NUL on the

150 first ref. The peeled value of a ref (that is "ref^{}") MUST be

151 immediately after the ref itself, if presented. A conforming server

152 -MUST peel the ref if its an annotated tag.

152 +MUST peel the ref if it's an annotated tag.

153

154 ----

155 advertised-refs = (no-refs / list-of-refs)

@@ -261,7 +261,7 @@ Without either multi_ack or multi_ack_detailed:

261

262 * upload-pack sends "NAK" on a flush-pkt if no common object

263 has been found yet. If one has been found, and thus an ACK

264 - was already sent, its silent on the flush-pkt.

264 + was already sent, it's silent on the flush-pkt.

265

266 After the client has gotten enough ACK responses that it can determine

267 that the server has enough information to send an efficient packfile

@@ -271,9 +271,9 @@ as common with the server, or the --date-order queue is empty), or the

271 client determines that it wants to give up (in the canonical implementation,

272 this is determined when the client sends 256 'have' lines without getting

273 any of them ACKed by the server - meaning there is nothing in common and

274 -the server should just send all it's objects), then the client will send

274 +the server should just send all of its objects), then the client will send

275 a 'done' command. The 'done' command signals to the server that the client

276 -is ready to receive it's packfile data.

276 +is ready to receive its packfile data.

277

278 However, the 256 limit *only* turns on in the canonical client

279 implementation if we have received at least one "ACK %s continue"

@@ -286,7 +286,7 @@ ACK after 'done' if there is at least one common base and multi_ack or

286 multi_ack_detailed is enabled. The server always sends NAK after 'done'

287 if there is no common base found.

288

289 -Then the server will start sending it's packfile data.

289 +Then the server will start sending its packfile data.

290

291 ----

292 server-response = *ack_multi ack / nak

Documentation/technical/protocol-capabilities.txt

+2 -2

@@ -60,7 +60,7 @@ doesn't, as in the following diagram:

60 If the client wants x,y and starts out by saying have F,S, the server

61 doesn't know what F,S is. Eventually the client says "have d" and

62 the server sends "ACK d continue" to let the client know to stop

63 -walking down that line (so don't send c-b-a), but its not done yet,

63 +walking down that line (so don't send c-b-a), but it's not done yet,

64 it needs a base for x. The client keeps going with S-R-Q, until a

65 gets reached, at which point the server has a clear base and it all

66 ends.

@@ -181,7 +181,7 @@ delete-refs

181 -----------

182

183 If the server sends back the 'delete-refs' capability, it means that

184 -it is capable of accepting an zero-id value as the target

184 +it is capable of accepting a zero-id value as the target

185 value of a reference update. It is not sent back by the client, it

186 simply informs the client that it can be sent zero-id values

187 to delete references.

Documentation/user-manual.txt

+1 -1

@@ -1196,7 +1196,7 @@ the time, you will want to commit your changes before you can merge,

1196 and if you don't, then linkgit:git-stash[1] can take these changes

1197 away while you're doing the merge, and reapply them afterwards.

1198

1199 -If the changes are independant enough, Git will automatically complete

1199 +If the changes are independent enough, Git will automatically complete

1200 the merge and commit the result (or reuse an existing commit in case

1201 of <<fast-forwards,fast-forward>>, see below). On the other hand,

1202 if there are conflicts--for example, if the same file is

Fix typos in technical documentation.