[holodorum]

This PR adds support for multiple ranges to blame instead of a single-range. This is compatible with git's behavior. Using git it's possible to blame multiple ranges as follows:

git blame example.rs -L 1,2 -L 2,3 

This results in a blame of lines 1-3 in example.rs. After this update we are able to run the same command using gix!

Initially I tried implementing this without the refactoring to a BlameRanges type. However, it became messy quickly because the ranges had the type Option<Vec<std::ops::Range<u32>>> type. With BlameRanges the complexity is quite comprehensible I feel.

A possible improvement could be to add an enum that signals whether the ranges are zero_based or one_based.

[Byron]

Thanks so much, this looks great!

Please note that I did refactor the commits to properly indicate breakage with conventional commits, and there are some other refactors too which you might find interesting.

Also CC Christoph Rüßler (@cruessler) just in case he'd like to see other changes in a follow-up, the reason I merge it already is that it's implemented very non-invasively without basically no changes to the algorithm itself.

[holodorum]

Wow that was quick! And thank you, there are some insightful refactors and updates :)

[cruessler]

Bart Dubbeldam (@holodorum) Sebastian Thiel (@Byron) Just a couple of minor observations, some possibly nitpicky, so feel free to ignore. :-)

• It might have made sense to also rename options.range to options.ranges as now there is a slight inconsistency, in particular between options.range and BlameRanges.
• Is there a reason the initial construction of ranges is done via Vec::with_capacity and a for loop instead of via collect?
• Since BlameRanges is now its own type (which I really like), I think we could still write a couple of unit tests in addition to the unit tests added for gix_blame::file.
• Should the AsRange parser be renamed to AsInclusiveRange for consistency?

Apart from that, I think this is already a great addition!

[cruessler]

Also, I feel there’s a certain contradiction in calling the method is_empty while returning a non-empty Vec in to_zero_based_exclusive. Can we find a name for is_empty that communicates its intent in a different way?

[holodorum]

That are some good suggestions, thanks Christoph Rüßler (@cruessler).
I feel the same about that is_empty check. What about an enum along these lines?

enum BlameRangesState {
    Empty,
    OneInclusive(BlameRanges),
    ZeroInclusive(BlameRanges),
}

[cruessler]

is_empty doesn’t seem to be used anymore, so it could also be removed at this point. 😄

[Byron]

Apologies for being so merge-happy 😅, next time I will wait for your review.
Maybe there could be a follow-up or a refactor-commit with the next contribution of Bart Dubbeldam (@holodorum) .

[cruessler]

Sebastian Thiel (@Byron) No worries! I think we can address all comments in a follow-up PR as you suggest.