[PATCH] Add --only-merges flag to display only merge commits.

This is the opposite of git-rev-list --no-merges: It will hide commits
with single or no parent.

It is useful if a maintainer has a lot of commits between tags and
usually each feature is developed in its own topic branch.

Signed-off-by: Miklos Vajna <redacted>
---

I just wanted to see the list of merges since the last tag in a repo
where we have 1000+ commits and about 20 merges and found that there is
no easy way to do so.

As a side effect, git rev-list --no-merges --only-merges will list
nothing, but that's logical IMHO.

 Documentation/git-rev-list.txt     |    1 +
 Documentation/rev-list-options.txt |    4 ++++
 builtin-rev-list.c                 |    1 +
 builtin-rev-parse.c                |    1 +
 revision.c                         |    7 +++++++
 revision.h                         |    1 +
 6 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index d80cdf5..17c26bc 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt

@@ -15,6 +15,7 @@ SYNOPSIS
 	     [ \--min-age=timestamp ]
 	     [ \--sparse ]
 	     [ \--no-merges ]
+	     [ \--only-merges ]
 	     [ \--first-parent ]
 	     [ \--remove-empty ]
 	     [ \--full-history ]

diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 2648a55..fc1cf0f 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt

@@ -176,6 +176,10 @@ endif::git-rev-list[]
 
 	Do not print commits with more than one parent.
 
+--only-merges::
+
+	Do not print commits with less than two parents.
+
 --first-parent::
 	Follow only the first parent commit upon seeing a merge
 	commit.  This option can give a better overview when

diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index edc0bd3..35c9422 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c

@@ -23,6 +23,7 @@ static const char rev_list_usage[] =
 "    --min-age=epoch\n"
 "    --sparse\n"
 "    --no-merges\n"
+"    --only-merges\n"
 "    --remove-empty\n"
 "    --all\n"
 "    --branches\n"

diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 0351d54..66a6b62 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c

@@ -47,6 +47,7 @@ static int is_rev_argument(const char *arg)
 		"--max-count=",
 		"--min-age=",
 		"--no-merges",
+		"--only-merges",
 		"--objects",
 		"--objects-edge",
 		"--parents",

diff --git a/revision.c b/revision.c
index 196fedc..1f92a1a 100644
--- a/revision.c
+++ b/revision.c

@@ -1127,6 +1127,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 				revs->no_merges = 1;
 				continue;
 			}
+			if (!strcmp(arg, "--only-merges")) {
+				revs->only_merges = 1;
+				continue;
+			}
 			if (!strcmp(arg, "--boundary")) {
 				revs->boundary = 1;
 				continue;

@@ -1517,6 +1521,9 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
 		return commit_ignore;
 	if (revs->no_merges && commit->parents && commit->parents->next)
 		return commit_ignore;
+	if (revs->only_merges && ((commit->parents && !commit->parents->next) ||
+			!commit->parents))
+		return commit_ignore;
 	if (!commit_match(commit, revs))
 		return commit_ignore;
 	if (revs->prune && revs->dense) {

diff --git a/revision.h b/revision.h
index c8b3b94..c40cf33 100644
--- a/revision.h
+++ b/revision.h

@@ -32,6 +32,7 @@ struct rev_info {
 	unsigned int	dense:1,
 			prune:1,
 			no_merges:1,
+			only_merges:1,
 			no_walk:1,
 			show_all:1,
 			remove_empty_trees:1,

-- 
1.5.4.5

Hi,

On Tue, 8 Apr 2008, Miklos Vajna wrote:

This is the opposite of git-rev-list --no-merges: It will hide commits 
with single or no parent.

It is useful if a maintainer has a lot of commits between tags and 
usually each feature is developed in its own topic branch.

Signed-off-by: Miklos Vajna <redacted> ---

I just wanted to see the list of merges since the last tag in a repo
where we have 1000+ commits and about 20 merges and found that there is
no easy way to do so.

I usually did something like this:

git log -1 $(git rev-list --parents | sed -n "s/ .* .*//p")

Hth,
Dscho

On Wed, Apr 09, 2008 at 04:06:57PM +0200, Johannes Schindelin [off-list ref] wrote:

quoted

I just wanted to see the list of merges since the last tag in a repo
where we have 1000+ commits and about 20 merges and found that there is
no easy way to do so.

I usually did something like this:

git log -1 $(git rev-list --parents | sed -n "s/ .* .*//p")

If you mean:

git log -1 $(git rev-list --parents HEAD | sed -n "s/ .* .*//p")

then it'll show only the first merge, --only-merges shows each merge.
(While of course you can still use -1 or tag.. or so.)

Hi,

On Wed, 9 Apr 2008, Miklos Vajna wrote:

On Wed, Apr 09, 2008 at 04:06:57PM +0200, Johannes Schindelin [off-list ref] wrote:

quoted

quoted

I just wanted to see the list of merges since the last tag in a repo
where we have 1000+ commits and about 20 merges and found that there is
no easy way to do so.

I usually did something like this:

git log -1 $(git rev-list --parents | sed -n "s/ .* .*//p")

If you mean:

git log -1 $(git rev-list --parents HEAD | sed -n "s/ .* .*//p")

Yes, I meant "something like" that...

then it'll show only the first merge, --only-merges shows each merge. 
(While of course you can still use -1 or tag.. or so.)

Yep, I wrote "-1", but what I actually meant was "--no-walk".

Sorry,
Dscho

On Wed, Apr 09, 2008 at 05:00:14PM +0200, Johannes Schindelin [off-list ref] wrote:

quoted

then it'll show only the first merge, --only-merges shows each merge. 
(While of course you can still use -1 or tag.. or so.)

Yep, I wrote "-1", but what I actually meant was "--no-walk".

Oh, I see. But I still think it would be handy to have an option for
this if there is an option to filter out merges as well.

Miklos Vajna [off-list ref] writes:

This is the opposite of git-rev-list --no-merges: It will hide commits
with single or no parent.

It is useful if a maintainer has a lot of commits between tags and
usually each feature is developed in its own topic branch.

For that particular use case, I'd suggest --first-parent.  It is not just
about filtering the output but more importantly also affects the way the
traversal is done (it does not descend into side branches).  It simply is
more suited for the job you described.

At this point, I have a mild aversion to a random addition to rev-list
that does not have to affect how the traversal works but only filters the
output, and more importantly does only a single purpose filtering.

It is very much unclear if the --only-merges is a very common thing for
people to want to do, and it is very clear what --only-merges does is a
very narrow single purpose filtering.

Contrast that to existing --no-merges or --grep.  The former is a very
narrow single purpose filtering but it is clearly something everybody
would want to have.  The latter also satisfies a common desire, and it is
an easy way to query with a customized filtering, e.g. you can use it like
so: 'log --grep="Merge " v1.5.4..v1.5.5'.

On Wed, Apr 09, 2008 at 01:06:19PM -0700, Junio C Hamano [off-list ref] wrote:

Miklos Vajna [off-list ref] writes:

quoted

This is the opposite of git-rev-list --no-merges: It will hide commits
with single or no parent.

It is useful if a maintainer has a lot of commits between tags and
usually each feature is developed in its own topic branch.

For that particular use case, I'd suggest --first-parent.  It is not just
about filtering the output but more importantly also affects the way the
traversal is done (it does not descend into side branches).  It simply is
more suited for the job you described.

Hm I was not exactly correct. Trivial fixes are pushed to master
directly, so just --first-parent won't solve my problem.

It is very much unclear if the --only-merges is a very common thing for
people to want to do, and it is very clear what --only-merges does is a
very narrow single purpose filtering.

OK, that's something others should decide. :-) I find it useful but maybe
it's not commonly useful.

Contrast that to existing --no-merges or --grep.  The former is a very
narrow single purpose filtering but it is clearly something everybody
would want to have.  The latter also satisfies a common desire, and it is
an easy way to query with a customized filtering, e.g. you can use it like
so: 'log --grep="Merge " v1.5.4..v1.5.5'.

Oh, I forgot about --grep. Though I still think --only-merges would be a
solution and --grep="Merge " is just a workaround, in practice it works
fine, so thanks for the hint. :-)