b62c769730 · matheusbsbs/matheus-bagliano

@@ -2,20 +2,20 @@ SPECIFYING REVISIONS

2 --------------------

3

4 A revision parameter '<rev>' typically, but not necessarily, names a

5 -commit object. They use what is called an 'extended SHA1'

5 +commit object. It uses what is called an 'extended SHA1'

6 syntax. Here are various ways to spell object names. The

7 -ones listed near the end of this list are to name trees and

7 +ones listed near the end of this list name trees and

8 blobs contained in a commit.

9

10 '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::

11 The full SHA1 object name (40-byte hexadecimal string), or

12 - a substring of such that is unique within the repository.

12 + a leading substring that is unique within the repository.

13 E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both

14 - name the same commit object if there are no other object in

14 + name the same commit object if there is no other object in

15 your repository whose object name starts with dae86e.

16

17 '<describeOutput>', e.g. 'v1.7.4.2-679-g3bee7fb'::

18 - An output from `git describe`; i.e. a closest tag, optionally

18 + Output from `git describe`; i.e. a closest tag, optionally

19 followed by a dash and a number of commits, followed by a dash, a

20 'g', and an abbreviated object name.

21

@@ -27,30 +27,30 @@ blobs contained in a commit.

27 When ambiguous, a '<name>' is disambiguated by taking the

28 first match in the following rules:

29

30 - . if '$GIT_DIR/<name>' exists, that is what you mean (this is usually

30 + . If '$GIT_DIR/<name>' exists, that is what you mean (this is usually

31 useful only for 'HEAD', 'FETCH_HEAD', 'ORIG_HEAD', 'MERGE_HEAD'

32 and 'CHERRY_PICK_HEAD');

33

34 - . otherwise, 'refs/<name>' if exists;

34 + . otherwise, 'refs/<name>' if it exists;

35

36 - . otherwise, 'refs/tags/<refname>' if exists;

36 + . otherwise, 'refs/tags/<refname>' if it exists;

37

38 - . otherwise, 'refs/heads/<name>' if exists;

38 + . otherwise, 'refs/heads/<name>' if it exists;

39

40 - . otherwise, 'refs/remotes/<name>' if exists;

40 + . otherwise, 'refs/remotes/<name>' if it exists;

41

42 - . otherwise, 'refs/remotes/<name>/HEAD' if exists.

42 + . otherwise, 'refs/remotes/<name>/HEAD' if it exists.

43 +

44 -'HEAD' names the commit your changes in the working tree is based on.

45 -'FETCH_HEAD' records the branch you fetched from a remote repository

44 +'HEAD' names the commit on which you based the changes in the working tree.

45 +'FETCH_HEAD' records the branch which you fetched from a remote repository

46 with your last `git fetch` invocation.

47 -'ORIG_HEAD' is created by commands that moves your 'HEAD' in a drastic

47 +'ORIG_HEAD' is created by commands that move your 'HEAD' in a drastic

48 way, to record the position of the 'HEAD' before their operation, so that

49 -you can change the tip of the branch back to the state before you ran

50 -them easily.

51 -'MERGE_HEAD' records the commit(s) you are merging into your branch

49 +you can easily change the tip of the branch back to the state before you ran

50 +them.

51 +'MERGE_HEAD' records the commit(s) which you are merging into your branch

52 when you run `git merge`.

53 -'CHERRY_PICK_HEAD' records the commit you are cherry-picking

53 +'CHERRY_PICK_HEAD' records the commit which you are cherry-picking

54 when you run `git cherry-pick`.

55 +

56 Note that any of the 'refs/*' cases above may come either from

@@ -60,7 +60,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

60 A ref followed by the suffix '@' with a date specification

61 enclosed in a brace

62 pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1

63 - second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value

63 + second ago\}' or '\{1979-02-26 18:30:00\}') specifies the value

64 of the ref at a prior point in time. This suffix may only be

65 used immediately following a ref name and the ref must have an

66 existing log ('$GIT_DIR/logs/<ref>'). Note that this looks up the state

@@ -70,7 +70,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

70

71 '<refname>@\{<n>\}', e.g. 'master@\{1\}'::

72 A ref followed by the suffix '@' with an ordinal specification

73 - enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify

73 + enclosed in a brace pair (e.g. '\{1\}', '\{15\}') specifies

74 the n-th prior value of that ref. For example 'master@\{1\}'

75 is the immediate prior value of 'master' while 'master@\{5\}'

76 is the 5th prior value of 'master'. This suffix may only be used

@@ -79,16 +79,16 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

79

80 '@\{<n>\}', e.g. '@\{1\}'::

81 You can use the '@' construct with an empty ref part to get at a

82 - reflog of the current branch. For example, if you are on the

83 - branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.

82 + reflog entry of the current branch. For example, if you are on

83 + branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.

84

85 '@\{-<n>\}', e.g. '@\{-1\}'::

86 - The special construct '@\{-<n>\}' means the <n>th branch checked out

86 + The construct '@\{-<n>\}' means the <n>th branch checked out

87 before the current one.

88

89 '<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::

90 The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to

91 - the branch the ref is set to build on top of. Missing ref defaults

91 + the branch the ref is set to build on top of. A missing ref defaults

92 to the current branch.

93

94 '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::

@@ -102,9 +102,9 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

102 '<rev>{tilde}<n>', e.g. 'master{tilde}3'::

103 A suffix '{tilde}<n>' to a revision parameter means the commit

104 object that is the <n>th generation grand-parent of the named

105 - commit object, following only the first parent. I.e. '<rev>{tilde}3' is

105 + commit object, following only the first parents. I.e. '<rev>{tilde}3' is

106 equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to

107 - '<rev>{caret}1{caret}1{caret}1'. See below for a illustration of

107 + '<rev>{caret}1{caret}1{caret}1'. See below for an illustration of

108 the usage of this form.

109

110 '<rev>{caret}\{<type>\}', e.g. 'v0.99.8{caret}\{commit\}'::

@@ -113,7 +113,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

113 could be a tag, and dereference the tag recursively until an

114 object of that type is found or the object cannot be

115 dereferenced anymore (in which case, barf). '<rev>{caret}0'

116 - introduced earlier is a short-hand for '<rev>{caret}\{commit\}'.

116 + is a short-hand for '<rev>{caret}\{commit\}'.

117

118 '<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::

119 A suffix '{caret}' followed by an empty brace pair

@@ -124,7 +124,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

124 '<rev>{caret}\{/<text>\}', e.g. 'HEAD^{/fix nasty bug}'::

125 A suffix '{caret}' to a revision parameter, followed by a brace

126 pair that contains a text led by a slash,

127 - is the same as ':/fix nasty bug' syntax below except that

127 + is the same as the ':/fix nasty bug' syntax below except that

128 it returns the youngest matching commit which is reachable from

129 the '<rev>' before '{caret}'.

130

@@ -133,8 +133,8 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

133 a commit whose commit message matches the specified regular expression.

134 This name returns the youngest matching commit which is

135 reachable from any ref. If the commit message starts with a

136 - '!', you have to repeat that; the special sequence ':/!',

137 - followed by something else than '!' is reserved for now.

136 + '!' you have to repeat that; the special sequence ':/!',

137 + followed by something else than '!', is reserved for now.

138 The regular expression can match any part of the commit message. To

139 match messages starting with a string, one can use e.g. ':/^foo'.

140

@@ -145,19 +145,19 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.

145 ':path' (with an empty part before the colon)

146 is a special case of the syntax described next: content

147 recorded in the index at the given path.

148 - A path starting with './' or '../' is relative to current working directory.

149 - The given path will be converted to be relative to working tree's root directory.

148 + A path starting with './' or '../' is relative to the current working directory.

149 + The given path will be converted to be relative to the working tree's root directory.

150 This is most useful to address a blob or tree from a commit or tree that has

151 - the same tree structure with the working tree.

151 + the same tree structure as the working tree.

152

153 ':<n>:<path>', e.g. ':0:README', ':README'::

154 A colon, optionally followed by a stage number (0 to 3) and a

155 colon, followed by a path, names a blob object in the

156 - index at the given path. Missing stage number (and the colon

156 + index at the given path. A missing stage number (and the colon

157 that follows it) names a stage 0 entry. During a merge, stage

158 1 is the common ancestor, stage 2 is the target branch's version

159 (typically the current branch), and stage 3 is the version from

160 - the branch being merged.

160 + the branch which is being merged.

161

162 Here is an illustration, by Jon Loeliger. Both commit nodes B

163 and C are parents of commit node A. Parent commits are ordered

revisions.txt: language improvements