Hi, Matthew DeVore wrote: > On 2019/05/09, at 11:00, Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: >> - Supporting any combination of filter means that we have more to >> implement and test, especially if we want to support more filters in >> the future. In particular, the different filters (e.g. blob, tree) >> have different code paths now in Git. One way to solve it would be to >> combine everything into one monolith, but I would like to avoid it if >> possible (after having to deal with revision walking a few times...) > > I don’t believe there is any need to introduce monolithic code. The > bulk of the filter implementation is in list-objects-filter.c, and I > don’t think the file will get much longer with an additional filter > that “combines” the existing filter. The new filter is likely > simpler than the sparse filter. Once I add the new filter and send > out the initial patch set, we can discuss splitting up the file, if > it appears to be necessary. > > My idea - if it is not clear already - is to add another OO-like > interface to list-objects-filter.c which parallels the 5 that are > already there. Sounds good to me. For what it's worth, my assumption has always been that we would eventually want the filters to be stackable. So I'm glad you're looking into it. Jonathan's reminder to clean up as you go is a welcome one. Thanks, Jonathan
