> To be honest, the main reason I spawn here is that I did not want to be > bothered with resetting the commit flags after traversing the first commit > range. But I guess I was just too cheap and should really do it? Oh right, you'd have to do multiple revision walks. > OTOH spawning here is a lot easier than not spawning, so maybe it would be > premature optimization? Most likely. > >> In addition to that patch, we'd have to buffer commit messages >> and buffer multiple commits, as that only buffers a diff of a single >> commit. > > ... and make sure that the moved-code logic (which is currently the only > user of emitted_symbols, correct?) would never be called at the same time > as we generate the diff. The moved detection is all part of the flags of an emitted symbol. By design the emitted symbol has easy access to the raw line of the output, which made it easy for the move detection to work on the lines. AFAICT this is also desired here as lines are put into a hashmap for comparisons. (and having it colored differently would make finding the same line complex using hashmaps) I just entertain the thought of having move detection active in a branch-diff. That would be really cool actually. > >> The benefit would be no invocation of new processes, letting us >> do more in core. This would allow for tweaking revision walking >> internally, e.g. passing of options to this command such as rename >> detection factors, can be passed through easily without the need >> of translating it back to the command line. > > On the other hand, we can simply copy those options to the command-line > for `log`. Which might even be better, as e.g. `--format` changes global > state :-( ok. Thanks for your patience, Stefan
