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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
