Re: [PATCH v2 5/5] Add tests around status handling of ignored arguments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jameson Miller <jameson.miller81@xxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux