threads / patch / 13025

patchAdd --only-merges flag to display only merge commits.

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

## tl;dr

7 messages between Apr 8, 2008 and Apr 9, 2008. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Miklos Vajna· Apr 8, 2008, 20:36 UTC · lore

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 <vmiklos@frugalware.org>
---

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(-)
Show changes to 6 files +15 −0

Documentation/git-rev-list.txt, Documentation/rev-list-options.txt, builtin-rev-list.c, builtin-rev-parse.c, revision.c, revision.h

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
Johannes Schindelin· Apr 9, 2008, 14:06 UTC · re: Miklos Vajna · lore

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

Hi,
On Tue, 8 Apr 2008, Miklos Vajna wrote:
Show 11 quoted lines
> 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 <vmiklos@frugalware.org> ---
> 
> 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

Miklos Vajna· Apr 9, 2008, 14:51 UTC · re: Johannes Schindelin · lore

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

On Wed, Apr 09, 2008 at 04:06:57PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 7 quoted lines
> > 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.)

Johannes Schindelin· Apr 9, 2008, 15:00 UTC · re: Miklos Vajna · lore

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

Hi,
On Wed, 9 Apr 2008, Miklos Vajna wrote:
Show 12 quoted lines
> On Wed, Apr 09, 2008 at 04:06:57PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > 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

Miklos Vajna· Apr 9, 2008, 18:31 UTC · re: Johannes Schindelin · lore

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

On Wed, Apr 09, 2008 at 05:00:14PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 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.

Junio C Hamano· Apr 9, 2008, 20:06 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:
Show 5 quoted lines
> 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'.

Miklos Vajna· Apr 9, 2008, 20:38 UTC · re: Junio C Hamano · lore

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

On Wed, Apr 09, 2008 at 01:06:19PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Miklos Vajna <vmiklos@frugalware.org> 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.

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.

Show 5 quoted lines
> 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. :-)

← back to recent threads