Miklos Vajna <vmiklos@frugalware.org> writes:

quoted text
> 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'.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html