Aaron Lipman <alipman88@xxxxxxxxx> writes: >> 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? > > Yes, that is how I've implemented this. (Your wording may be more > clear, I'll plan on updating the commit message.) > >> 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. > > I think we're on the same page: If a branch is merged into 'seen' but > not 'next', it should show up in the output of > "git branch --merged seen --merged next". > > If a branch is merged into 'master' but not 'maint', it should not > show up in the output of > "git branch --no-merged master --no-merged maint". > > To clarify, is that the behavior that makes sense/seems useful to you? > If so, I can add some test cases for those filter combinations in v2. Yup, drawing the parallel to how revision walker combines multiple positive and negative starting points would feel the most natural to experienced Git users, I would say. Thanks.
