CommitsBetweenRequest

Class Overview

Defines a request to retrieve commits "between" sets of included and excluded commits, potentially filtering by paths.

The easiest way to understand commits "between" is with an illustration:

 "feature-B"               FB1 -- FB2 -- FB3
                           /      /
                          /      /
 "master"    ---- A ---- B ---- C
                   \
                    \
 "feature-A"        FA1 -- FA2 -- FA3
 

Given the graph above, here are some examples of the commits "between" various points:

• Include "FA3", exclude "C": "FA1", "FA2", "FA3"
  • "FA3" also references "A", but, since "A" is reachable from "C", it is excluded from the results
  • This might be used to list the commits that have been added on a feature branch and not yet merged
• Include "master", exclude "feature-A": "B", "C"
  • "feature-A" is resolved to "FA-3", excluding "FA2", "FA1" and "A", while "master" is resolved to "C" and includes "B"
  • This might be used to list commits added on an upstream branch after a feature branch was created which have not yet been merged into the feature branch
• Include "feature-B", exclude "FB1" and "C": "FB2", "FB3"
  • "feature-B" is resolved to "FB3", which includes "FB2" and "FB1" as well as "A", "B" and "C" from "master". Excluding "C" drops "A" and "B" as well
  • This might be used, for example, to determine which commits have been added when a pull request is rescoped, excluding the previous from ref and the current to ref yields the just the added commits
• Include "FB1" and "C", exclude "feature-B": No commits
  • This is the logical negation of the previous example. When a pull request is rebased, this could be used to determine which commits were removed from the pull request by showing commits that used to be reachable from "FB1" but are no longer reachable from "FB3" or "C"

The first two examples demonstrate how the selected commits vary, given the same set of possible commits, depending on which commits are included and excluded. As might be expected, excluding a commit takes precedence over including it. The second two examples show how using multiple includes and excludes can be used to determine how a pull request has been changed by a rescope event.

Also useful when dealing with pull requests is the ability to determine the commits between two repositories. When a secondary repository is specified its commits will be made available in the primary repository, which allows retrieving the commits that have been added on a branch in a fork, for example, when opening a pull request back to its origin. When a secondary repository is specified, it must be from the same hierarchy as the primary repository or an exception will be thrown while building the request.

Warning: Retrieving commits between repositories may be expensive. Additionally, when referring to commits in the secondary repository, includes and excludes must be specified by hash. Branch and tag names are always resolved using the primary repository, which may lead to unexpected results.

Note: Once built, a request is immutable. None of the returned collections may be modified.

Summary

Nested Classes
class	CommitsBetweenRequest.Builder

[Expand] Inherited Constants
From class com.atlassian.bitbucket.commit.AbstractCommitsRequest int UNLIMITED_MESSAGE_LENGTH A symbolic constant for max message length which means the full commit message should be read regardless of length.

Public Methods
@Nonnull Set<String>	getExcludes() Retrieves commits, which may be identified by branch or tag name or by hash, which should be excluded from the results.
@Nonnull Set<String>	getIncludes() Retrieves commits, which may be identified by branch or tag name or by hash, which should be included in the results.
int	getMaxMessageLength()
@Nonnull Set<String>	getPaths() Retrieves paths, which may identify directories or files within the repository, which are used to limit returned commits.
@Nonnull Set<String>	getPropertyKeys() Retrieves the keys of index properties to load for returned commits.
@Nonnull Repository	getRepository() Retrieves the primary repository.
@Nullable Repository	getSecondaryRepository() When retrieving commits between repositories, retrieves the secondary repository.
boolean	isFollowingRenames() Whether or not the commit history will attempt to follow renames.
@Deprecated @Nullable Boolean	isIgnoringMissing() This method is deprecated. in 4.5. This return type will change to boolean in 5.0.

[Expand] Inherited Methods
From class com.atlassian.bitbucket.commit.AbstractCommitsRequest int getMaxMessageLength() @Nonnull CommitListMergeFilter getMerges() Retrieves the strategy being used to filter merge commits. @Nonnull Set<String> getPaths() Retrieves paths, which may identify directories or files within the repository, which are used to limit returned commits. @Nonnull Set<String> getPropertyKeys() Retrieves the keys of index properties to load for returned commits. @Nonnull Repository getRepository() boolean isFollowingRenames() Whether or not the commit history will attempt to follow renames. @Nullable @Deprecated Boolean isIgnoringMissing() This method is deprecated. in 4.6. This return type will change to boolean in 5.0.
From class java.lang.Object Object clone() boolean equals(Object arg0) void finalize() final Class<?> getClass() int hashCode() final void notify() final void notifyAll() String toString() final void wait(long arg0, int arg1) final void wait(long arg0) final void wait()