1git-rev-list(1) 2=============== 3 4NAME 5---- 6git-rev-list - Lists commit objects in reverse chronological order 7 8 9SYNOPSIS 10-------- 11[verse] 12'git-rev-list' [ \--max-count=number ] 13 [ \--skip=number ] 14 [ \--max-age=timestamp ] 15 [ \--min-age=timestamp ] 16 [ \--sparse ] 17 [ \--no-merges ] 18 [ \--remove-empty ] 19 [ \--not ] 20 [ \--all ] 21 [ \--stdin ] 22 [ \--topo-order ] 23 [ \--parents ] 24 [ \--encoding[=<encoding>] ] 25 [ \--(author|committer|grep)=<pattern> ] 26 [ [\--objects | \--objects-edge] [ \--unpacked ] ] 27 [ \--pretty | \--header ] 28 [ \--bisect ] 29 [ \--bisect-vars ] 30 [ \--merge ] 31 [ \--reverse ] 32 [ \--walk-reflogs ] 33 <commit>... [ \-- <paths>... ] 34 35DESCRIPTION 36----------- 37 38Lists commit objects in reverse chronological order starting at the 39given commit(s), taking ancestry relationship into account. This is 40useful to produce human-readable log output. 41 42Commits which are stated with a preceding '{caret}' cause listing to 43stop at that point. Their parents are implied. Thus the following 44command: 45 46----------------------------------------------------------------------- 47 $ git-rev-list foo bar ^baz 48----------------------------------------------------------------------- 49 50means "list all the commits which are included in 'foo' and 'bar', but 51not in 'baz'". 52 53A special notation "'<commit1>'..'<commit2>'" can be used as a 54short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of 55the following may be used interchangeably: 56 57----------------------------------------------------------------------- 58 $ git-rev-list origin..HEAD 59 $ git-rev-list HEAD ^origin 60----------------------------------------------------------------------- 61 62Another special notation is "'<commit1>'...'<commit2>'" which is useful 63for merges. The resulting set of commits is the symmetric difference 64between the two operands. The following two commands are equivalent: 65 66----------------------------------------------------------------------- 67 $ git-rev-list A B --not $(git-merge-base --all A B) 68 $ git-rev-list A...B 69----------------------------------------------------------------------- 70 71gitlink:git-rev-list[1] is a very essential git program, since it 72provides the ability to build and traverse commit ancestry graphs. For 73this reason, it has a lot of different options that enables it to be 74used by commands as different as gitlink:git-bisect[1] and 75gitlink:git-repack[1]. 76 77OPTIONS 78------- 79 80Commit Formatting 81~~~~~~~~~~~~~~~~~ 82 83Using these options, gitlink:git-rev-list[1] will act similar to the 84more specialized family of commit log tools: gitlink:git-log[1], 85gitlink:git-show[1], and gitlink:git-whatchanged[1] 86 87include::pretty-formats.txt[] 88 89--relative-date:: 90 91 Show dates relative to the current time, e.g. "2 hours ago". 92 Only takes effect for dates shown in human-readable format, such 93 as when using "--pretty". 94 95--header:: 96 97 Print the contents of the commit in raw-format; each record is 98 separated with a NUL character. 99 100--parents:: 101 102 Print the parents of the commit. 103 104Diff Formatting 105~~~~~~~~~~~~~~~ 106 107Below are listed options that control the formatting of diff output. 108Some of them are specific to gitlink:git-rev-list[1], however other diff 109options may be given. See gitlink:git-diff-files[1] for more options. 110 111-c:: 112 113 This flag changes the way a merge commit is displayed. It shows 114 the differences from each of the parents to the merge result 115 simultaneously instead of showing pairwise diff between a parent 116 and the result one at a time. Furthermore, it lists only files 117 which were modified from all parents. 118 119--cc:: 120 121 This flag implies the '-c' options and further compresses the 122 patch output by omitting hunks that show differences from only 123 one parent, or show the same change from all but one parent for 124 an Octopus merge. 125 126-r:: 127 128 Show recursive diffs. 129 130-t:: 131 132 Show the tree objects in the diff output. This implies '-r'. 133 134Commit Limiting 135~~~~~~~~~~~~~~~ 136 137Besides specifying a range of commits that should be listed using the 138special notations explained in the description, additional commit 139limiting may be applied. 140 141-- 142 143-n 'number', --max-count='number':: 144 145 Limit the number of commits output. 146 147--skip='number':: 148 149 Skip 'number' commits before starting to show the commit output. 150 151--since='date', --after='date':: 152 153 Show commits more recent than a specific date. 154 155--until='date', --before='date':: 156 157 Show commits older than a specific date. 158 159--max-age='timestamp', --min-age='timestamp':: 160 161 Limit the commits output to specified time range. 162 163--author='pattern', --committer='pattern':: 164 165 Limit the commits output to ones with author/committer 166 header lines that match the specified pattern. 167 168--grep='pattern':: 169 170 Limit the commits output to ones with log message that 171 matches the specified pattern. 172 173--remove-empty:: 174 175 Stop when a given path disappears from the tree. 176 177--no-merges:: 178 179 Do not print commits with more than one parent. 180 181--not:: 182 183 Reverses the meaning of the '{caret}' prefix (or lack thereof) 184 for all following revision specifiers, up to the next '--not'. 185 186--all:: 187 188 Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the 189 command line as '<commit>'. 190 191--stdin:: 192 193 In addition to the '<commit>' listed on the command 194 line, read them from the standard input. 195 196-g, --walk-reflogs:: 197 198 Instead of walking the commit ancestry chain, walk 199 reflog entries from the most recent one to older ones. 200 When this option is used you cannot specify commits to 201 exclude (that is, '{caret}commit', 'commit1..commit2', 202 nor 'commit1...commit2' notations cannot be used). 203+ 204With '\--pretty' format other than oneline (for obvious reasons), 205this causes the output to have two extra lines of information 206taken from the reflog. By default, 'commit@{Nth}' notation is 207used in the output. When the starting commit is specified as 208'commit@{now}', output also uses 'commit@{timestamp}' notation 209instead. Under '\--pretty=oneline', the commit message is 210prefixed with this information on the same line. 211 212--merge:: 213 214 After a failed merge, show refs that touch files having a 215 conflict and don't exist on all heads to merge. 216 217--boundary:: 218 219 Output uninteresting commits at the boundary, which are usually 220 not shown. 221 222--dense, --sparse:: 223 224When optional paths are given, the default behaviour ('--dense') is to 225only output commits that changes at least one of them, and also ignore 226merges that do not touch the given paths. 227 228Use the '--sparse' flag to makes the command output all eligible commits 229(still subject to count and age limitation), but apply merge 230simplification nevertheless. 231 232--bisect:: 233 234Limit output to the one commit object which is roughly halfway between 235the included and excluded commits. Thus, if 236 237----------------------------------------------------------------------- 238 $ git-rev-list --bisect foo ^bar ^baz 239----------------------------------------------------------------------- 240 241outputs 'midpoint', the output of the two commands 242 243----------------------------------------------------------------------- 244 $ git-rev-list foo ^midpoint 245 $ git-rev-list midpoint ^bar ^baz 246----------------------------------------------------------------------- 247 248would be of roughly the same length. Finding the change which 249introduces a regression is thus reduced to a binary search: repeatedly 250generate and test new 'midpoint's until the commit chain is of length 251one. 252 253--bisect-vars:: 254 255This calculates the same as `--bisect`, but outputs text ready 256to be eval'ed by the shell. These lines will assign the name of 257the midpoint revision to the variable `bisect_rev`, and the 258expected number of commits to be tested after `bisect_rev` is 259tested to `bisect_nr`, the expected number of commits to be 260tested if `bisect_rev` turns out to be good to `bisect_good`, 261the expected number of commits to be tested if `bisect_rev` 262turns out to be bad to `bisect_bad`, and the number of commits 263we are bisecting right now to `bisect_all`. 264 265-- 266 267Commit Ordering 268~~~~~~~~~~~~~~~ 269 270By default, the commits are shown in reverse chronological order. 271 272--topo-order:: 273 274 This option makes them appear in topological order (i.e. 275 descendant commits are shown before their parents). 276 277--date-order:: 278 279 This option is similar to '--topo-order' in the sense that no 280 parent comes before all of its children, but otherwise things 281 are still ordered in the commit timestamp order. 282 283--reverse:: 284 285 Output the commits in reverse order. 286 287Object Traversal 288~~~~~~~~~~~~~~~~ 289 290These options are mostly targeted for packing of git repositories. 291 292--objects:: 293 294 Print the object IDs of any object referenced by the listed 295 commits. 'git-rev-list --objects foo ^bar' thus means "send me 296 all object IDs which I need to download if I have the commit 297 object 'bar', but not 'foo'". 298 299--objects-edge:: 300 301 Similar to '--objects', but also print the IDs of excluded 302 commits prefixed with a "-" character. This is used by 303 gitlink:git-pack-objects[1] to build "thin" pack, which records 304 objects in deltified form based on objects contained in these 305 excluded commits to reduce network traffic. 306 307--unpacked:: 308 309 Only useful with '--objects'; print the object IDs that are not 310 in packs. 311 312Author 313------ 314Written by Linus Torvalds <torvalds@osdl.org> 315 316Documentation 317-------------- 318Documentation by David Greaves, Junio C Hamano, Jonas Fonseca 319and the git-list <git@vger.kernel.org>. 320 321GIT 322--- 323Part of the gitlink:git[7] suite