Aaron Lipman <alipman88@xxxxxxxxx> writes: > Enable ref-filter to process multiple merged and no-merged filters, and > extend functionality to git branch, git tag and git for-each-ref. This > provides an easy way to check for branches that are "graduation > candidates:" > > $ git branch --no-merged master --merged next > > To accomplish this, store the merged and no-merged filters in two > commit_list structs (reachable_from and unreachable_from) rather than > using a single commit struct (merge_commit). > > If passed more than one merged (or more than one no-merged) filter, > mirror the existing boolean logic used by contains/no-contains filters: > refs must satisfy any of the merged filters, and all of the no-merged > filters. I am not sure if the parallel with "contains" should hold in the first place. The way I would look at the --[no-]merged is that I'm enumerating commits that would be shown in this corresponding revision walking command: $ git log --decorate --oneline ^master ^maint next seen If the tip of a branch appears in that output, then the branch is included in the corresponding "git branch" output, and if it does not, the branch is excluded from the corresponding "git branch" output. $ git branch \ --no-merged master --no-merged maint \ --merged next --merged seen That would mean the rule would be "refs must be reachable by any one (or more) of the <merged> commits, and must be reachable by none of the <no-merged> commits". I am not using the same phrasing you used (i.e. "must satisify ... filter"), but are we saying the same thing? It is unclear to me what you meant by "all of the no-merged filters". The expectation is that topics in flight are either reachable from 'next' or 'seen' (there can be commits in 'next' but not in 'seen' when fixes to mismerges are involved) and those already graduated are either in 'master' or 'maint', and the above "log" and "branch" would show the stuff still in flight. But if you mean by "all of the no-merged filters" that it must be in both 'master' and 'maint' for a commit to be excluded from the output, it would not behave as I would expect. In _my_ history, since 'maint' is always kept as a subset to 'master' because I refrain from cherry-picking a fix that is in 'master' down to 'maint', I can use a single "--no-merged master" to work around the problem, but in a larger scale projects where cherry-picking fixes to maintainance track is more common, the above does not sound so useful, at least at the first glance. So I dunno. Thanks.
