Jameson Miller <jameson.mille...@gmail.com> writes: >> Hmph, having some tests in 3/5, changes in 4/5 and even more tests >> in 5/5 makes me as a reader a bit confused, as the description for >> these two test patches does not make it clear how they are related >> and how they are different. Is it that changes in 1/5 alone does >> not fulfill the promise made by documentation added at 2/5 so 3/5 >> only has tests for behaviour that works with 1/5 alone but is broken >> with respect to what 2/5 claims until 4/5 is applied, and these "not >> working with 1/5 alone, but works after 4/5" are added in this step? > > Correct. The changes in 1/5 are to implement "--ignored=matching" > with "--untracked-files=all" with corresponding tests in 3/5. The > changes in 4/5 are to implement "--ignored=matching" > with "--untracked-files=normal" and the corresponding tests are > in 5/5. > > Do you have a preference on how I organized this work? I see > several possible ways to split up this work. Maybe it would be > less confusing to have the implementation in the first two > commits, then 1 commit with all the tests, and then a commit with > the documentation? I think it makes sense to have the logic for > the different flag combinations split into their own commits, but > I am open to any suggestions.
Yeah, there are some alternatives, all valid. Support matching/all combination in 1/5, document that in 2/5, test that in 3/5 and then do the same 3-patch series to support matching/normal combination in 4/5, 5/5 and 6/5 would be one. Doing code, doc and test for matching/all in one patch and doing code, doc and test for matching/normal in another patch, resulting in a two-patch series may be another. Or your "code for matching/all in 1/5, code for matching/normal in 2/5, doc and test for both in subsequent steps" is fine, too. All of these would not leave things in inconsistent state when we interrupt the series in the middle, which is a desirable property for those who want to understand the topic.
