>> Please avoid adjectives that express subjective values, like
>> "sophisticated". Readers will expect a lot more sophistication than
>> your code actually offers and will be disappointed ("wow, that would
>> be wonderful if we can say 'exclude commits made by bots, and those
>> older than 3 months'---eh, you cannot do that? where is your
>> sophistication then?").
I use it("sophisticated") from "packfile-uri.txt", but i agree with you.
Documentation will also remove/replace the subjective word in the next
patch.
>> Please avoid "should" without first describing the background for
>> "why it should". It would help if you briefly describe what we
>> currently have and its limitation before this first paragraph
>> (i.e. your "we can already exclude only blob objects" would become
>> major part of the explanation, but you'd need to present in what
>> situations it would help to be able to exclude other types).
Agree.
Commit message will be appended with backgroud description.
>> This commit is probalby doing too many things at once. For example,
>> refactoring like creation of match_packfile_uri_exclusions() helper
>> function out of existing code (there probably are others) can and
>> should be done as separate preparatory steps before the API gets
>> modified (e.g. process-object callbacks gain an e xtra parameter) in
>> tree-wide way.
>>
>> And by slimming the primary step that introduces the new feature,
>> there will be a space to also add documentation and test in the same
>> step, which would help reviewers. With the current structure of the
>> series, with a code dump in the first step with only a vague promiss
>> of "sophistication" without documentation updates, reviewers cannot
>> even tell how the "commit object" is used easily.
Agree.
The current commit will be splitted for more clear reponsibilities,
documentation and tests ditto.
Thank you.
