On Wed, Apr 09, 2008 at 01:06:19PM -0700, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> 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. > 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. :-)
Attachment:
pgproG12MfGSP.pgp
Description: PGP signature
