RevisionSpecification

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated. Please visit git-scm.com/doc for up-to-date documentation.

This section describes various ways to specify what revisions you are interested in. Aside from being used by git-log(1) and git-whatchanged(1), they may also be used with graphical frontends such as gitk.

---

Table of contents:

---

Limit by Path Name

If you are interested only in those revisions that made changes

to a specific file (or even several files) list the files like this:

$ git log Makefile README

To avoid ambiguity between repository references, such as tag name, and filenames, separate file names from other git options using `--`. So if you have a file named master it will clash with the reference

named master, and thus you will have to use:

$ git log -- master

Limit by Date or Number

You can limit the amount of history to show from a given revision. Either limit by date using e.g. `--since=1.month` or `--since=2.weeks.ago`, or limit by the number of commits using `-n400` (or deprecated `-15`).

If you are only interested in changed that happened between two dates

you can use:

$ git log --after="May 5th" --before="2006-05-16 15:44"

Note:

   If you want to avoid having to quote dates containing spaces you can
   use "." instead, e.g. `--after=May.5th`.

Limiting by Commit Ranges

Often you are interested in what happened between two revisions, such as between two releases. For this reason, commits can be limited to a specific

range, such as "all commits between tag-1.0 and tag-2.0". For example:

$ git log tag-1.0..tag-2.0

This way of commit limiting makes it trivial to only browse the commits which haven't been pushed to a remote branch. Assuming origin is your

upstream remote branch, using:

$ git log origin..HEAD

will list what changes are pending to be pushed to the remote branch. Optionally, the ending or beginning `HEAD` can be left out since it is implied.

Limiting by Reachability

Git interprets the range specifier "tag-1.0..tag-2.0" as "all commits reachable from tag-2.0 but not from tag-1.0". Where reachability refers to what commits are ancestors (or part of the history) of the branch or tagged revision in question. If you prefer to specify which commits you

are interested in this way use the following:

$ git log tag-2.0 ^tag-1.0

You can think of `^` as a negation operator. Using this alternate syntax, it is possible to further prune commits by specifying multiple "cut offs".

For example you can say a <sup>b </sup>c ^d or a --not b c d for the more complex case where you're interested in one (or more) commit, but not anything that flows from any of a number of other commits.

Combining Revision Specifications

Revisions options can to some degree be combined, which makes it possible to say "show at most 20 commits from within the last month that changed

files under the Documentation/ directory."

$ git log --since=1.month -n20 -- Documentation/

Examining All Repository References

In some cases, it can be useful to query changes across all references in a repository. This is especially useful if you are using a visualization tool such at gitk. An example is to query "did any line of development in this repository change a particular file within the last week?"

This can be accomplished using:

$ gitk --all --since=1.week -- Makefile

Another example:

$ gitk --all --since=1.month -15 -- t/

will show at most fifteen commits from any branch that changed the test subdirectory in the last month.

---

References

• More examples can be found in the Git

tutorial's
section about "Exploring History".

• Relevant man pages:

git-log(1),
git-rev-list(1), and
the section on "Specifying Revisions" in
git-rev-parse(1).

---