Gabriel Nützi
Gabriel Nützi
@dpc: Some question for undestanding the problem better: Do you think it makes sense to make a new trait `Flushable` which a Drain instance can have where it would implement...
Ah maybe its better to add this functionality to the `Drain` with a default implementation?
Not really sure if that feature is needed: The use case was #35 : - Make the worker thread somehow stop processing records (not implemented) - Flush all pending stuff...
any progress?
I'd rather call it "modules". Also [PR1204R0](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1204r0.html) should be integrated probably in some sense. (it already fits, with merged header placement) and could be mentioned as an addendum for beeing...
Actually, we could just drop most features (eventough they seem nice, are they really needed? @N etc..) You certainly almost always know from where to where you genereate the log....
Why I come with this: there is no way to generate the log from HEAD to lastTag (without the Tag!)...
Sorry I was not clear: I meant from HEAD to first next tag... (not including the tag). Say HEAD contains v1.4.0 and after 3 commits v1.3.9 comes... because closed ranges...
Ok it seams that just works, by not giving any arguments.
Ok, strange things happen when some tag is somewhere else (not seen from HEAD) The behavior you certainly want is to replace your current parsing with `git rev-parse --first-parent` with...