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. :-)