> > Fine, I guess the reason for this mystery is I "push" this branch to github > > and you haven't done it. That may not be due to the platform. Because I > > can see no this bug happening when I use a new git repo without "git push", > > and I test in archlinux or deepin, this bug will happen in these environments. > > Sorry, you lost me. I was talking about what happens in the new > test you added to t6302 not failing as designed, and there shouldn't > be "I've pushed but you haven't pushed to GitHub" distinction. The > test is running in a brand-new repository just created for the sole > purpose of running the test after all. > Well, there are some expression problems here, I just want to express: This bug is only triggered after I push and Git adds some config during the push process. And then those config effort %(push) behavior. > So in short, the test script added to t6302 in the v4 patch was not > testing what it was supposed to be testing, as it didn't have the > configuration items related to %(push) atom necessary to trigger the > error? > Truly. > That I can believe. I was starting to worry if there was something > more subtle going on, but I am glad that it was only an uncooked > patch submitted without checking. > Me too, I want to complain a little bit: this bug is too difficult to locate. > > I guess you also saw this bug: > > > > BUG: ref-filter.c:1544: unhandled RR_* enum > > No, I didn't. I just tried to make sure the new test was truly > checking the existing breakage by partially reverting the code fix, > and saw that the new test did not fail. > I understand. > Thanks. Thanks. -- ZheNing Hu
