Philippe Blain <levraiphilippeblain@xxxxxxxxx> writes: > * In patch 6, I considered fixing that bug in a different way by > initializing sb.path inside blame.c::setup_scoreboard. This function > already receives 'path' as its second argument, so changing that would not > impact the API. Probably Thomas thought that sb.path was already > initialized in sb when he modified builtin/blame.c::prepare_blame_range > to also send sb.path to line-range.c::parse_range_arg in 13b8f68c1f (log > -L: :pattern:file syntax to find by funcname, 2013-03-28). > > Initializing the path in setup_scoreboard would mean we could also > simplify the API of blame.c::setup_blame_bloom_data since it would not > need to receive path separately and so its second argument could be > removed. I went for the simpler alternative of just sending 'path' to > parse_range_arg instead of sb.path since it felt simpler, but if we feel > it would be better to actually initialize sb.path in setup_scoreboard, > I'll gladly tweak that for v2. > >> But that is merely a potential future clean-up. The local variable >> path is still used one more time in the error message given when >> this parse_range_arg() fails, so at least this change makes the use >> of path more consistent. I like the simplicity of this fix. > > I also like its simplicity, and that's why I chose to submit this as v1. > But I completely agree with you that it is "dangerous" in the sense > that some further modifications to the code could then make the same mistake > and use 'sb.path' thinking it is defined when it is not. > > So I'm thinking of instead initializing it in setup_scoreboard for v2. That does sound like a sensible way to clean it up. Thanks.
