.SH "SYNOPSIS"
.nf
-git\-rev\-list [ \-\-max\-count=number ]
+\fIgit\-rev\-list\fR [ \-\-max\-count=number ]
[ \-\-max\-age=timestamp ]
[ \-\-min\-age=timestamp ]
[ \-\-sparse ]
[ \-\-no\-merges ]
[ \-\-remove\-empty ]
[ \-\-all ]
- [ [ \-\-merge\-order [ \-\-show\-breaks ] ] | [ \-\-topo\-order ] ]
+ [ \-\-topo\-order ]
[ \-\-parents ]
- [ \-\-objects [ \-\-unpacked ] ]
+ [ [\-\-objects | \-\-objects\-edge] [ \-\-unpacked ] ]
[ \-\-pretty | \-\-header ]
[ \-\-bisect ]
<commit>... [ \-\- <paths>... ]
Lists commit objects in reverse chronological order starting at the given commit(s), taking ancestry relationship into account\&. This is useful to produce human\-readable log output\&.
-Commits which are stated with a preceding ^ cause listing to stop at that point\&. Their parents are implied\&. "git\-rev\-list foo bar ^baz" thus means "list all the commits which are included in foo and bar, but not in baz"\&.
+Commits which are stated with a preceding \fI^\fR cause listing to stop at that point\&. Their parents are implied\&. "git\-rev\-list foo bar ^baz" thus means "list all the commits which are included in \fIfoo\fR and \fIbar\fR, but not in \fIbaz\fR"\&.
A special notation <commit1>\&.\&.<commit2> can be used as a short\-hand for ^<commit1> <commit2>\&.
.TP
\-\-objects
-Print the object IDs of any object referenced by the listed commits\&. git\-rev\-list \-\-objects foo ^bar thus means "send me all object IDs which I need to download if I have the commit object bar, but not foo"\&.
+Print the object IDs of any object referenced by the listed commits\&. \fIgit\-rev\-list \-\-objects foo ^bar\fR thus means "send me all object IDs which I need to download if I have the commit object \fIbar\fR, but not \fIfoo\fR"\&.
+
+.TP
+\-\-objects\-edge
+Similar to \-\-objects, but also print the IDs of excluded commits refixed with a \- character\&. This is used by git\-pack\-objects to build \fIthin\fR pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic\&.
.TP
\-\-unpacked
.TP
\-\-bisect
-Limit output to the one commit object which is roughly halfway between the included and excluded commits\&. Thus, if git\-rev\-list \-\-bisect foo bar baz outputs midpoint, the output of git\-rev\-list foo ^midpoint and git\-rev\-list midpoint bar baz would be of roughly the same length\&. Finding the change which introduces a regression is thus reduced to a binary search: repeatedly generate and test new 'midpoint's until the commit chain is of length one\&.
+Limit output to the one commit object which is roughly halfway between the included and excluded commits\&. Thus, if \fIgit\-rev\-list \-\-bisect foo bar baz\fR outputs \fImidpoint\fR, the output of \fIgit\-rev\-list foo ^midpoint\fR and \fIgit\-rev\-list midpoint bar baz\fR would be of roughly the same length\&. Finding the change which introduces a regression is thus reduced to a binary search: repeatedly generate and test new 'midpoint's until the commit chain is of length one\&.
.TP
\-\-max\-count
\-\-topo\-order
By default, the commits are shown in reverse chronological order\&. This option makes them appear in topological order (i\&.e\&. descendant commits are shown before their parents)\&.
-.TP
-\-\-merge\-order
-When specified the commit history is decomposed into a unique sequence of minimal, non\-linear epochs and maximal, linear epochs\&. Non\-linear epochs are then linearised by sorting them into merge order, which is described below\&.
-
-Maximal, linear epochs correspond to periods of sequential development\&. Minimal, non\-linear epochs correspond to periods of divergent development followed by a converging merge\&. The theory of epochs is described in more detail at http://blackcubes\&.dyndns\&.org/epoch/: \fIhttp://blackcubes.dyndns.org/epoch/\fR\&.
-
-The merge order for a non\-linear epoch is defined as a linearisation for which the following invariants are true:
-
-.RS
-.TP 3
-1.
-if a commit P is reachable from commit N, commit P sorts after commit N in the linearised list\&.
-.TP
-2.
-if Pi and Pj are any two parents of a merge M (with i < j), then any commit N, such that N is reachable from Pj but not reachable from Pi, sorts before all commits reachable from Pi\&.
-
-Invariant 1 states that later commits appear before earlier commits they are derived from\&.
-
-Invariant 2 states that commits unique to "later" parents in a merge, appear before all commits from "earlier" parents of a merge\&.
-.LP
-.RE
-.IP
-
-.TP
-\-\-show\-breaks
-Each item of the list is output with a 2\-character prefix consisting of one of: (|), (^), (=) followed by a space\&.
-
-Commits marked with (=) represent the boundaries of minimal, non\-linear epochs and correspond either to the start of a period of divergent development or to the end of such a period\&.
-
-Commits marked with (|) are direct parents of commits immediately preceding the marked commit in the list\&.
-
-Commits marked with (^) are not parents of the immediately preceding commit\&. These "breaks" represent necessary discontinuities implied by trying to represent an arbitrary DAG in a linear form\&.
-
-\-\-show\-breaks is only valid if \-\-merge\-order is also specified\&.
-
.SH "AUTHOR"
Written by Linus Torvalds <torvalds@osdl\&.org>
-
-Original \-\-merge\-order logic by Jon Seymour <jon\&.seymour@gmail\&.com>
-
.SH "DOCUMENTATION"
projects / git.git / blobdiff