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

quoted text
> 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.

quoted text
> 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=3D"Merge " v1.5.4..v1.5.5'.

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